软件工程
项目开发中文档的作用
- 文档也是软件产品的一部分，没有文档的软件就不能称之为软件
- 文档是开发中的重要工具，对开发有较大意义。
- 软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量
- 高质量文档对于发挥软件产品的效益有着重要的意义
例题讲解【2021上】
11.00 开发模型前言
开发模型
概念：软件工程当中指导开发的一种开发思想，开发体系
- 不同开发模型分不同阶段
11.01 瀑布模型（SDLC）
由来
- 197几年提出，随着时代发展逐渐退出神坛
淘汰原因
- 延期，成本超支，做不下去
瀑布模型特点
- 每层会有评审
- 制定了标准化
- 是一个结构化方法当中的模型
瀑布模型升级版—添加回溯功能
淘汰底层原理
需求阶段难以把控
- 做到最后面，客户需求不对等之后需要重新返工
适用场合
需求明确和二次开发
总结
- 结构化方法中的模型
- 只适用于需求明确的项目
11.02 原型、演化、增量模型
原型模型
- 适用于需求不明确的时候
- 一般用在需求分析阶段
步骤：
- 项目开发初期，构造一个简易的系统【可以是一个界面原型或者初步系统】
- 客户就可以可视化看到，提出更好的需求
- 在经过多轮的调整
演化模型
- 通过多轮演化原型成为最终产品
螺旋模型
- 原型+瀑布+演化模型特征的思想称为
- 将风险分析加入到了该模型中
- 适合于大规模、复杂且具有高风险的项目
- 螺旋模型将开发过程划分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符
- 在螺旋模型中过多的迭代次数会增加开发成本
增量模型
- 原型+瀑布模型特征的思想称为
- 可以快速提供一个初始化版本给用户
步骤
- 先做项目的核心模块
- 做好后先拿去给客户用，然后修正相应问题
- 同理一部分一部分的开发模块，使项目越来越大，最终成为最终产品
总结
- 原型模型强调构造一个简易的系统，针对需求不明确的情况
11.03 增量模型与螺旋模型
螺旋模型
- 原型+瀑布+演化模型特征的思想称为
- 将风险分析加入到了该模型中
- 适合于大规模、复杂且具有高风险的项目
- 螺旋模型将开发过程划分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符
- 在螺旋模型中过多的迭代次数会增加开发成本
增量模型
- 原型+瀑布模型特征的思想称为
- 可以快速提供一个初始化版本给用户
问：需求不明确的项目选原型还是螺旋模型？
- 选原型
例题讲解【2021上】
11.04 V模型
这种模型，测试有了更重要的地位
- 强调测试的模型
与瀑布模型的区别：
- 瀑布模型：先铺路，在拉线测试路直不直，不直就打掉重新铺
- 验证能找到问题，但是修正问题成本过高
- V模型：先拉水平线，才开始铺路
V型的初衷：
- 如图两边有着对应关系
- 需求分析结束后就去写：验收测试和系统测试的计划
- 概要设计【模块设计】结束后就去写：集成测试
- 详细设计结束后就去写：单元测试
总结
之前模型都是结构化方法当中的模型
11.05 喷泉模型与RAD
喷泉模型
特点
- 面向对象模型
- 所以就继承了面向对象的特性：迭代和无间隙
RAD（快速开发模型）
目前常用
- 可以快速构建应用系统
- 由SDLC（瀑布模型）和CBSD（构件组装模型）组合
- 简单理解就是：可视化开发
11.06 构件组装模型（CBSD）
基本思路
- 把软件开发当中的各个模块，都可以考虑做成标准的构件
- 将构件进行组织，就得到了最终的软件
优势
- 极大提高了软件开发的复用性
- 开发时间，成本降低
- 软件可靠性增加
- 构件过程会创建一个构件库，再新开发软件的时候就可以直接利用库里构件
开发步骤
11.07 统一过程（UP，以前叫RUP）
应用于大型项目【目前常用】
特点
- 用例驱动的：创建好用例之后，各个阶段都通过用例来推动
- 以架构为中心
- 迭代与增量
开发过程：
- 初始阶段：核心阶段为
创建用例 - 细化阶段：核心阶段为
建立软件架构基础【完成架构】 - 构建阶段：核心阶段为
构建的组装 - 交付阶段：核心阶段为
β测试——用户阶段测试，比如qqbate测试版本，下上供用户使用测试
- 还有一种是α测试：开发环境去做的【了解】
- 这个1.0版本交付之后，再有问题或者更新迭代就在等2.0版本的交付（新的一轮）
11.08 敏捷开发方法
应用场景：小型项目
目的
- 由于前面追求高质量开发模型，造成文档过多（还不一定能用到），所以提出该模型来减轻开发人员的负担
- 把不必要的文档减去
敏捷开发方法是一组模型
例题讲解：关于敏捷开发中极限编程（XP）相关知识
企业信息化战略与实施
11.09 信息系统开发方法
信息系统开发方法主要分为四类
结构化法
缺点
- 一旦开发完成，它的流程是固化的，不灵活的
- 后期要改非常的麻烦，所以就出现了后面的面向对象法
原型法
- 主要用在需求分析阶段
- 做一个简易的系统，给客户用来探明需求
- 适用于需求不明确的开发
- 补的是结构化方法（比如：瀑布模型）的短板
面向对象法
- 将现实的人或物抽象成对象，不同对象用属性来区分，对象能干什么就写成方法
- 相当于开发就是在组件流程
面向服务法
- 了解概念和SOA（面向服务结构）即可
需求工程
11.10 需求的分类
- 设计约束
- 比如：这个平台可以用php和java开发，但是需求方只会用java开发
- QFD（质量展开功能）
- 基本需求：客户提出来的
- 期望需求：用户没有提出，但是理所应当提供的需求
- 兴奋需求：客户没提出来，开发自行补充的一些功能
- 不该做，因为提高了项目开发时间，若逾期则由项目组承担
系统设计
11.11 结构化设计
概念：结构化方法当中软件设计问题
基本原则
- 多扇入，少扇出【就是多是别人调用我，我调用的模块尽量少】
- 多层模块调用当中，上层模块调用A模块（下层），称为扇入
- 被A模块调用的称为扇出
例题讲解：
模块设计原则的考察
模块控制域：这个模块本身以及所有直接或间接从属于它的模块的集合。
模块作用域：指受该模块内一个判定所影响的所有模块的集合。
模块的作用域应该在控制域范围之内【重点】
例题讲解【2021年上】
软件详细设计阶段与软件概要设计阶段
软件详细设计阶段
软件详细设计阶段的主要任务包括：对模块内的数据结构进行设计；对数据库进行物理设计；对每个模块进行详细的算法设计；代码设计、输入/输出设计、用户界面设计等其他设计。
软件概要设计阶段
软件概要设计阶段的主要任务包括
- 软件系统总体结构设计，将系统划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
- 数据结构及数据库设计。
例题讲解【2021上】
内聚和耦合
- 内聚：一个模块内部各个部件连接的紧密程度
- 耦合：模块与模块之间的衡量概念
注意： - 图中内聚程度由高到低排列
- 图中耦合程度由低到高排列
扩展：耦合类型
- 数据耦合是通过参数表传递简单信息。
- 公共耦合是多个模块访问同一个公共数据环境。
- 外部耦合是一组模块访问同一个全局简单变量而没有通过参数表传递。
- 内容耦合是一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口。本题描述的是内容耦合。
例题讲解【2021上】
例题讲解
系统结构/模块结构
软件测试是考点
11.12 测试原则与类型
测试原则
- 尚未发现的错误与已发现的错误成正比：就是A，B两个模块，A发现30个bug，B发现100个bug，则修改完之后主要去看B模块，因为它不够成熟还会有别的bug，而且新修改完的100也可能出现bug
测试类型
分为两大块
动态测试：利用到计算机的测试
- 灰盒就是把黑，白盒结合起来
静态测试：纯手工的测试
- 代码走查：就是看一段代码最后结果是多少
- 代码审查：我看你的代码，你看我的代码，一种交叉审查
11.13 测试用例设计
黑盒测试
- 知道输入和输出是什么，但是不知道内部结构
白盒测试
- 可以看到内部结构
- 白盒比黑盒更全面
- 语句覆盖和路径覆盖是两种具体的白盒测试方法
例题讲解【2021】
- 路径覆盖
例题讲解：2017年上
例题讲解：2017年下
第1题:1、两个测试用例，一个走真分支，一个走假分支即可。
第2题:2、看分支1：要走两个分支，则一个用例中A>2，另一个用例A<=2（此时，可排除D），
看分支2：要走两个分支，则其中一个用例必须满足A=5和X>3，
结合两个分支，则有一个用例为A=5，满足第一分支条件，且执行了X=X/A 后满足X>3，（X是int型）推出X>=20（此时，可推出选择B）。
可以再验证一下：
用例1：（1，1，5；5）
不满足分支1，也不满足分支2，走N—N；
用例2：（5，2，20；9）
满足分支1，X=X/A，则X=20/5=4；
继续执行，满足分支2，执行X=X+5=9，输出X=9。’
11.14 测试阶段
冒烟测试：做完修改后的一次充分的测试而已
- 理解：修好的管道里放进去烟气，哪里漏烟了，就表明哪里还有问题
几种测试的关系
- 先做单元测试，再做集成测试
- 普通项目，最后做确认测试
- 做集成项目时候（软硬件结合时候），会先做系统测试，再做确认测试
单元测试（1）
关注的是模块级（局部）的测试
集成测试（2）
- 各个模块联合起来测试，测试的是各个模块之间衔接，接口会不会有问题
- 需要完成组装
确认测试（3，集成项目时候（软硬件结合时候）是4）
- 根据需求来测试
- 产品（项目组用不到）测试往往才会用：Alpha测试和Beta测试
- Alpha测试：开发环境去做的
- Beta测试：用户环境去做的
- 验收测试：用户参与进来来决定是否愿意验收
系统测试【集成项目时候（软硬件结合时候）用到，变成第3个步骤】
- 偏重于压力，性能方面的测试
- 负载测试：并发1000的时候，响应多少毫秒
- 强度测试：资源突然下架能否应对
- 压力测试：在极限值情况
11.15 McCabe复杂度计算
考察：必考题
- 有向图G的环路复杂度公式：
V(G)=m-n+2 - 该题：边11条，8个点，结果是5
注意点：
- m是边，n是点
-
图转箭线图时候，抽象节点问题 - 连线交叉处不抽象为节点，直接连线可以，抽象为节点也可以
- 建议直接将分叉位置直接连线，不做抽象节点
例题讲解：2017年上
- 第二空，答案是4
11.16 系统运行与维护
考察：可维护性和维护类型
可维护性
- 概念：系统方面有什么缺陷，我们对系统做调整，会涉及到编码过程
- 易分析性：代码规范会影响这里
- 易改变性：代码耦合会影响这里
维护类型
在系统运行过程中，软件需要维护的原因是多样的，根据维护的原因不同，可以将软件维护分为以下四种：
改正性维护
- 改正性维护。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就称为改正性维护。
适应性维护
- 适应性维护。在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化，而去修改软件的过程就称为适应性维护。
完善性维护
- 完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动称为完善性维护。更快地得到搜索结果，即提升了搜索引擎的性能，扩充功能或提升性能是完善性维护的工作。
预防性维护
- 预防性维护。这是指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护可定义为“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编码和测试。
- 千年虫问题
例题讲解【2021上】
MTTF & MTTR
- MTTF：平均无故障时间
- MTTR：平均故障修复时间
例题讲解【2021上】
11.17 软件能力成熟度模型集成（CMMI）【重点考察】
考察：询问等级
CMM发展而来：能力成熟度模型
- 是软件开发的成熟度
- 判定软件承包商改善软件质量的能力
CMMI体系分为阶段式和连续式
阶段式
分五个等级
- 一级：混乱级
- 二级：已管理级（考虑项目级别问题——这个项目组会但是公司整体不会）
- 三级：已定义级（考虑公司，组织级别的问题——公司模板不完美，还有一些功能不完善，有项目组做成模板提供给公司）
- 四级：定量管理级（量化管理）
- 五级：优化级（持续优化）
连续式
该式更注重个人能力的发展，不需要按等级提升而是哪里缺失，哪里不足就直接去弥补哪里
11.18 项目管理基础知识【1-2分】
考察：时间管理的概念和计算；风险管理的概念
时间管理【进度管理->进度安排】
时间管理主要考两种图
Gantt图：用图来展示进度的安排
- 优势：可从图直观看到整个计划是什么样子的，计划开展时间等
- 缺点：过于简单不能清晰表达任务之间的依赖关系
项目活动图——PERT图【考试重点】：可以给出那些任务完成后才能开始另一些任务
- 主要了解计算问题
- 项目的最短工期：就是从开始到结束最长的路径
- 也称为：关键路径：完成整个工程\项目，所需最长时间的路径。
- 一般题目问：完成该项目的最短时长，就是求关键路径长度。
- 计算完成最少时间、某活动的松弛时间
- 任务的松弛时间：表示不影响整个工期的前提下，完成该任务有多少机动余地。
-
某个任务的松弛时间 = 工程关键路径 - 包含该任务的最长路径耗时 - 扩展知识
项目活动图——PERT图的例题讲解【2021上】
考点：
- 关键路径：完成整个工程\项目，所需最长时间的路径。
- 任务的松弛时间：表示不影响整个工期的前提下，完成该任务有多少机动余地。
-
某个任务的松弛时间 = 工程关键路径 - 包含该任务的最长路径耗时
时间管理例题讲解【综合题】
第一问：Gantt图得缺点不能清晰表达任务之间的依赖关系
第二问6最晚开始时间求解步骤
- 先正推，将所有的最早开始时间算出来
- 本题求出15，13，所以最迟开始时间是15
- 然后逆推的方式，把所有最晚开始时间求出来
- 逆推得结果10
风险管理
概念：损失或损害的可能性
- 风险是可能发生的事件，并且可能会带来损失，预测到风险后，可以进行干预以期减少损失，但是无法避免的
风险分类
- 项目风险：项目本来计划5万开发出来，结果用了10万
- 技术风险：用了新的技术带来的缝隙
- 商业风险：上面都做得很好，但是发现市场不需要这样的产品
风险曝光度=出现概率*可能的损失
- 量化一个风险，来衡量我们管理那些风险
例题讲解【2021】
