文章目录

• • 软件开发模型
  • • 1.瀑布模型---SDLC
  • 其他经典模型
  • • 增量模型、原型法
    • 螺旋模型
    • V模型
    • 喷泉模型
    • RAD---快速开发模型
    • 构建组装模型（CBSD）
    • 统一过程（UP）
    • 敏捷开发方法
  • 信息系统开发方法
  • 需求工程
  • 结构化设计
  • 软件测试
  • 测试用例设计
  • 软件测试--McCabe复杂度
  • 系统运行与维护
  • 软件过程改进--CMMI
  • 项目管理

软件开发模型

1.瀑布模型—SDLC

• 瀑布模型在过去火爆，但是现在已经淡出大众的视野

在每个阶段的末尾，都会有一个评审工作，并且强调工作的标准化，

但是瀑布模型有一个致命的缺点，导致项目往往不能完成：软件的需求往往难以把控

，尤其是项目初期，需求的不明确导致整个项目方向错误，而且需求改动难以满足，工作量巨大，导致软件项目的失败，导致瀑布模型难以满足软件的开发。

• 瀑布模型应用场景：
  • 需求明确
  • 二次开发（大部分需求是稳定的）

其他经典模型

增量模型、原型法

• 用户在初期很难确定需求（用户和人员之间有隔阂–>用户懂业务，开发人员懂技术）

• 原型法：先做出一个界面或者是一个简易的系统出来给用户，让他改需求针对需求不明确的情况，如果需求非常明确，可以用瀑布模型or其他模型

• 演化模型：原型不断升级最后演化为最终的产品

• 增量模型：原型法+瀑布模型

  • 在我们做系统的时候先把用户的核心需求做出来，让开发周期大大缩短（周期是原来周期的%20左右）

    然后逐步对其他增加功能进行开发，到最终完成所有的内容

  • 优点：核心内容比较早的和用户进行了接触，每一次将项目交给用户区看的时候，都再一次对项目进行了审视，风险较小

螺旋模型

• 特征：螺旋模型融合了多种模型，所以多个模型的特点，螺旋模型都具备

  在用户需求不明确的情况下，原型法的优先级大于螺旋模型的优先级

  • 风险分析：是螺旋模型最为显著的特点！

V模型

• V模型和瀑布模型和接近，但是V模型更加看重测试（单元测试、集成测试、系统测试、验收测试）
• V模型的缺点：测试压的太后了，当发现了错误，更改的成本比较高

V模型边设计，一遍编写测试文档，这样就可以减少开发时发生的错误

喷泉模型

• 特征：面向对象、迭代、无间隙，是面向对象的模型

RAD—快速开发模型

• 假如我们使用可视化工具进行开发，就算是RAD开发了

构建组装模型（CBSD）

• 我们把各个阶段开发过程做成标准的构件，最后将构件进行组装就得到了最终需要的软件

• 特征：极大的提高了软件开发的复用性，使得软件开发的总时长降低，成本降低，还可以使软件的可靠性增加

  一些我们以前在其他系统总进行开发的构件可以直接挪用过来，而这些构件已经经过了很长时间的验证，可靠性比较高

统一过程（UP）

特点：

• 用例驱动
  • 挖掘需求发现一些用例，然后实现这些用例，用例作为指导测试用例的开发依据
• 以架构为中心
  • 先把架构设计好，设计好架构，在向里面添加构件
• 迭代和增量
  • 每完成一个循环，就会有增量要做

β测试：软件在用户环境里进行测试

α测试：开发环境里进行测试

在测试有问题的部分在下一个周期进行修正，统一过程经过多伦的循环迭代才产生最终的产品

敏捷开发方法

敏捷开发方法的基本思想：减去没有必要的开发流程，减少开发人员的负担

一种轻量级的开发方法

敏捷开发方法是一个方法，而是多个方法的集合：

• 自适应方法
• 水晶方法
• 特征驱动方法
• SCRUM
• 极限编程

• 适合于开发小型项目，不适合大中型

信息系统开发方法

• 结构化方法（面向过程）

  • 用户至上
  • 严格区分工作阶段，每个阶段有任务和成果
  • 强调系统开发过程的整体性和全局性
  • 系统开发过程化，文档资料标准化
  • 自顶向下，逐步分解
  • 缺点：难以维护，升级，修改困难

• 面向对象方法

  • 复用性好
  • 关键在于建立一个全面、合理、统一的模型
  • 缺点：分析、设计、实现三个阶段，界限不明确

需求工程

1、业务需求：先分析当前业务、考虑功能、系统的大致功能

2、用户需求：询问相关业务的角色，进行沟通，根据反馈获取需求和相应的功能

3、系统需求：计算机化、能够开发的需求

系统需求：

• 功能需求
• 性能需求：相应时间、安全性、可靠性
• 设计约束：用户在软件设计时对开发提出的一定要求（语言要求、数据库类型…）

QFD需求：

• 基本需求：必须完成的需求

• 期望需求：用户认为理所应当达到的需求

• 兴奋要求：锦上添花，超出客户期望（谨慎）

结构化设计

特点：

• 自顶向下、逐步求精
• 信息隐蔽：函数内部信息不向外部展现
• 模块独立：高内聚、低耦合

内聚指标：（尽可能高）

内聚程度最大的是功能内聚，最小的是巧合内聚

耦合指标：

内容耦合程度最高，非直接耦合程度最低

原则：

• 多扇入，少扇出：

  被其他模块调用的多，而少调用其他模块（入度高、出度小）

三种模块结构

软件测试

• 测试应该尽早、不断的测试
• 程序员要避免测试自己的设计的程序
• 即要选择有效、合理的数据，也要选择无效、不合理的测试
• 修改后应该进行回归测试
• 尚未发现的错误数量与该程序已发现的错误数成正比（修改后将以前发现的错误也测试一下）

动态测试：利用到计算机进行测试

静态测试：纯人工测试

测试用例设计

黑盒测试（内部结构未知）

• 等价类划分
• 边界值分析
• 错误推测：经验分析
• 因果图：由结果分析原因

白盒测试（内部结构已知）

• 基本路径测试
• 循环覆盖测试
• 逻辑覆盖测试

软件测试–McCabe复杂度

有向图的环路复杂度公式：

V(G) = m-n+2

系统运行与维护

维护阶段是软件周期中时间最长的

可维护性：

• 可分析性：代码的规范程度高
• 易改变性：修改一段代码的容易程度（低耦合比较好）
• 稳定性
• 易测试性：测试的时候要做回归测试

维护类型：

• 改正性维护–25%
• 适应性维护–20%（升级、适应操作系统升级）
• 完善性维护–50%在系统的运行过程中，对系统的性能、功能进行升级
• 预防性维护–5%做一些预防性的工作，方便日后维护

软件过程改进–CMMI

CMMI是能力成熟度的集成

CMMI分为阶段式和连续式，对项目的评价、分类

• 阶段式

• 混乱级

• 已管理级–>基本的管理

• 已定义级 -->隐形的知识转化为显性

• 定量管理级—>量化

• 优化级–>持续的优化

• 连续式

项目管理

九大知识领域

• 时间管理

  • Gannt图（图结构显进度、计划）：不能清晰的表达任务之间的逻辑关系，但是可以清晰看出任务之间的并行性、任务进度等
  • PERT图可以只管的看到书屋之间的逻辑、先后关系

• 风险管理

• 项目风险：

  项目没控制好，导致成本增加

• 技术风险：

  新技术不成熟、旧技术太缓慢

• 商业风险：无法控制的风险（无法通过项目管理来控制）

（风险期望）