【软考笔记】10. 软件工程

软件开发模型

瀑布模型 SDLC

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bR18KukG-1683373444331)(/assets/瀑布模型.png)]

缺点：需求阶段难以把控

运用瀑布模型的场景：

1. 需求明确
2. 二次开发

原型模型，演化模型，增量模型

原型法：在项目开发的初期构造一个简易的系统，如一套界面/初步系统，然后跟用户沟通调整，针对需求不明确的情况

用于 需求分析 阶段

演化模型：原型 通过演化调整最终形成软件
增量模型：原型 + 瀑布模型，先做核心模块，给用户看，在这个基础上慢慢加其他模块，风险较小

螺旋模型

螺旋模型：原型 + 瀑布模型 + 演化模型

考试时，需求不明确的项目，让选择模型，备选项有原型模型，也有螺旋模型，虽然螺旋模型包含了原型的思想，仍然选择原型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dERmEHHD-1683373444332)(/assets/螺旋模型.png)]

特征：引入了 风险分析

V 模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u6le36LN-1683373444332)(/assets/V模型.png)]

特点：强调了测试，对测试进行了细化

需求分析 对应 验收测试、系统测试
概要设计 对应 集成测试
详细设计 对应 单元测试

从需求分析阶段就写验收测试的测试计划，这样就不会在最后才发现需求分析阶段有问题，从头改

喷泉模型

特点：面向对象的模型

1. 瀑布模型：结构化模型
2. 喷泉模型：面向对象的模型
   1. 迭代
   2. 无间隙

快速开发模型 RAD

快速开发模型 RAD = 瀑布模型 SDLC + 构件化开发模型 CBSD

特点：能快速构建应用系统

用 VB 等可视化开发就是 RAD

构建组装模型 CBSD

把各过程分别做成标准构建，再组装
把其他项目的模块拿来用

提高复用性 -> 提高开发速度，降低成本，提高可靠性

模块化设计

统一过程 UP 或 RUP

特点：

1. 用例驱动
2. 以架构为中心
3. 迭代与增量
   1. 每走一个循环有一个增量

初始：选架构
细化：完成架构
构建：组装构件（构件库里拿的），开发剩余构件（构件库里没有的）
交付：进行$\beta$测试（由用户做测试）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NY8gtziM-1683373444332)(/assets/统一过程模型.png)]

敏捷开发方法

减去不必要的文档和流程

适用于小型项目

信息系统开发方法

结构化法

工程化，文档标准化

缺点：不灵活

结构化设计

概要设计

详细设计

结构化设计的原则

1. 自顶向下，逐步求精
2. 信息隐蔽：函数里的内容不展示在外界，只展现接口
3. 模块独立：高内聚，低耦合，复杂度

详细的

1. 模块大小适中
2. 调用深度少
3. 多扇入，少扇出：入度高，出度低
   1. 入度：别的模块用自己多，说明价值高，好
   2. 出度：调用其他模块越多，说明模块自身职能多，不好
4. 单入口，单出口
5. 模块的作用域应在模块之内

内聚与耦合

掌握内聚和耦合的排序

从上到下内聚程度越来越低，耦合程度越来越高

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VotfnJat-1683373444333)(/assets/内聚与耦合.png)]

系统模块结构

传入型模块：向变换控制模块传入信息的模块
传出型模块：变换控制信息传出信息给到的模块
变换型模块：既有传入，又接收传出

原型法

适用于需求不明确的开发

面向对象方法

将系统设计到的物，抽象成对象
有更强的复用性

面向服务方法

三层：操作，服务，业务流程

需求工程

需求的分类

业务需求

明确这个系统总体是干啥的

用户需求

收集各角色的用户希望系统有哪些功能

系统需求

将用户需求转成能指导开发的需求

功能需求

性能需求（非功能需求）

如响应时间，安全性，可靠性

设计约束

既非功能需求也非性能需求，如客户要求用自主研发的数据库

从 QFD 的角度分类

基本需求

用户提出来的需求

期望需求

用户虽然没说，但觉得理所应当要达成的需求

兴奋需求

超越用户预期的需求，程序员要尽量规避

软件测试

测试的原则：

1. 尽早，不断测试
2. 程序员避免测试自己设计的程序
3. 既要选择有效，合理的数据，也要选择无效，不合理的数据
4. 修改后应进行回归测试
   1. 回归测试：重新测之前测过的模块
   2. 修正一个 bug 会引入新的 bug
5. 尚未发现的错误数量与已发现的错误数成正比
   1. 例：A 模块发现了 30 个 bug，B 模块发现 100 个 bug，后续要着重测试 B 模块

测试的分类

动态测试

用到计算机的测试

黑盒测试法

只知道输入某参数应该输出什么结果，不知道内部结构

1. 等价类划分
   1. 例：成绩管理系统，>=90 分为优，>=60 分为及格，选择 95 分和 80 分进行测试
2. 边界值分析
   1. 例：成绩管理系统，>=90 分为优，>=60 分为及格，选择 89 90 91 59 60 61 分进行测试
   2. 边界值就是正好边界的值，加上比边界稍小一点的，再加上比边界稍大一点的
3. 错误推测法：强调经验，灵感
4. 因果图：通过问题反推原因

白盒测试法

知道内部结构

着重了解逻辑覆盖测试

1. 基本路径测试
2. 循环路径测试
3. 逻辑覆盖测试
   1. 语句覆盖：层次最低
      1. 例：if(A>0) f11(); else f12(); if(B>0) f21(); else f22()
      2. 若只测 A>0&&B>0 和 A<=0&&B<=0 两个分支，虽然能完成语句覆盖，但是不全，所以语句覆盖层次最低
   2. 判定覆盖
      1. 例：判定是 A>0，A>0 和 A<=0 的两个分支都要覆盖
   3. 条件覆盖
      1. 例：条件是 A>0&&B<0，A>0，A<=0，B<0，B>=0 的四个分支都要覆盖
   4. 条件判定覆盖：组合条件和判定
   5. 路径覆盖：层次最高，包含了所有可能的情况

灰盒测试法

黑盒+白盒

静态测试

纯人工测试

桌前检查

程序员写完代码之后自己浏览一遍看有没有问题

代码走查

把代码执行一遍测试

代码审查

交叉检查

测试阶段

冒烟测试

取连接完电路，看会不会冒烟之意，冒烟说明电路连的有问题，短路了

是最初步的测试，测试有没有明显的问题

单元测试

测单个模块

集成测试

把多个模块联合起来进行测试，测模块之间的衔接

组装模块的方法

1. 一次性组装：全装上测
2. 增量式组装：一点一点装，装一点测一点

确认测试

确认需求是否达成

1. 内部确认测试
2. Alpha 测试
   1. 针对产品，项目开发人员接触不到
   2. 在开发环境测试
3. Beta 测试
   1. 针对产品，项目开发人员接触不到
   2. 在用户本地测试
4. 验收测试
   1. 用户接受最终产品

系统测试

偏重压力，性能方面，而非功能方面

考点：能区分 负载测试 强度测试 容量测试

1. 压力测试：在极限值的情况
   1. 例：设计供 1000 人使用的系统，在 100000 人的条件下会不会崩溃
2. 性能测试
   1. 负载测试
      1. 例：并发 1000 人、2000 人的响应时间
   2. 强度测试：发生异常时候
      1. 例：某资源突然下降，系统能否正常工作
   3. 容量测试

McCabe 复杂度（非常常考）

一个程序的代码可抽象成一个有向图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-27A2Xfu0-1683373444333)(/assets/代码抽象为有向图.png)]

有向图 G 的环路复杂度：
$$V(G)=m-n+2$$
V(G)：有向图 G 的路径个数
m：有向边数
n：节点数

系统运行与维护

考点：可维护性涉及的方面及维护的类型

可维护性

系统有缺陷，要编码解决

易分析性

易改变性

如果改变一个地方会影响很多模块，这是不好的
易改变性要求代码松耦合

稳定性

易测试性

维护类型

改正性维护

适应性维护

例：原先 windows2000 服务器，升级成 windows2008，系统需要相应维护使得在新环境中正常运行

数据环境发生变化后进行的维护，也是适应性维护的范畴

完善性维护

例：在系统的运行过程中，发现很多东西发生改变，要扩充功能（增加曲线图）、改善现有的性能

考试中，常常将适应性维护中数据环境发生变化的维护，和完善性维护相混淆来选

如果是单纯的加了功能，那就选完善性维护
如果是“为了适应外部市场环境变化”、“为了适应管理需求的改变”而增加功能，选适应性维护

预防性维护

现在不维护也没问题，但是将来可能有问题
闲时做一些文档方面的工作方便将来维护也属于预防性维护

软件过程改进（CMMI）

CMM：能力成熟度模型，衡量开发者改善软件质量的能力
CMMI：对 CMM 的集成和改进

阶段式：评价企业组织能力成熟度

考点：给一段描述，分析这个企业是 CMMI 的几级

一级：混乱级

没有进行 CMMI 认证的企业都属于混乱级

二级：已管理级

项目级：有过项目开发的经验（但是只是企业中的某些个人有，但是企业自身没有形成体系）

三级：已定义级

组织级：企业有一些标准的模板、规范，文档化 标准化

这些模板、规范称为 组织过程资产
个人在做项目的时候，可以把这些资产拿来用，也可以完善这些资产
将隐性的知识转化成显性的

四级：定量管理级

强调管理的 量化

五级：优化级

企业可以进行持续的 优化

连续式：评价软件过程能力成熟度

按照过程域来分，企业可以自行决定哪些方面的能力需要加强来实施

过程管理

项目管理

工程

支持

项目管理

考点 1：时间管理的概念和计算
考点 2：风险管理的概念

时间管理

甘特图（Gantt 图）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BKOI33wn-1683373444334)(/assets/甘特图.png)]

优点：简单明了
缺点：不能表达任务间的逻辑关系

PERT 图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KzIffAL5-1683373444334)(/assets/PERT图.png)]

考点：根据 PERT 图给出的最早开始时间，事件持续时间，最晚开始时间计算 关键路径

关键路径

从开始到结束节点最长的路径，对应整个项目的 最短工期

耗时最长的项目完成了，其他项目也就都完成了

求最晚开始时间

1. 正推求所有事件的最早开始时间
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MmaaFjY8-1683373444334)(/assets/PERT图%20-%20最早开始时间.png)]
2. 逆推求所有事件的最晚开始时间
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AF7oQVpg-1683373444334)(/assets/PERT图%20-%20最晚开始时间.png)]

风险管理

风险分类

技术风险

由技术因素导致

如：对某技术不熟悉
某技术是新技术，不成熟
某技术过于陈旧

项目风险

项目组没有做好

如：项目组没有控制好成本，使得花的钱超预算
项目组没有制定好计划，使得项目周期延长

商业风险

外部的问题

如：市场不需要该产品

风险曝光度

量化衡量风险是否重要的指标

计算风险曝光度

$$风险曝光度=风险发生的概率\times 风险造成的损失$$