本章框架
3.1软件生命周期
分3个阶段：如下
| 软件生命周期（Boehm） |
涉及人员 |
||
| 计划时期 |
1.问题定义 |
甲方：需要开发一个图书馆管理系统 乙方：问题定义。 首先需要对问题进行定义。比如说：有没有可行的解决方案；有可行方案后，还要弄明白方案执行需要多少执行人员？用到多少资金？需要用到多长时间？等 |
甲方：用户 乙方：系统分析师、项目负责人 |
| 2.可行性分析 |
根据问题定义进行可行性分析 |
||
| 开发时期 |
1.需求分析 |
明确信息系统有多少个模块组成。比如：信息系统到底要实现什么样的功能、性能、界面布局等反面的要求。 |
用户 系统分析师、项目负责人 |
| 2.总体设计 |
明确系统需要哪些功能之后，要对这些功能的实现进行概要设计（设计哪些模块） |
软件设计师、系统分析师 |
|
| 3.详细设计 |
对单一模块内部结构做进一步的详细设计 |
软件设计师、程序员 |
|
| 4.编码 |
把单个模块用程序代码的方式实现 |
程序猿 |
|
| 5.测试 |
乙方把做好的系统交付给甲方前的必要工作 |
测试工程师 |
|
| 运行时期 |
维护 |
乙方把做好的系统交付给甲方后，进入长期的维护阶段（整个软件生命周期中耗时最长） |
|
3.2软件开发模型
目标：掌握瀑布模型、演化模型、增量模型以及喷泉模型的概念及特点
1.瀑布模型：6各阶段，自上而下，且每个阶段按只做一次。（即通过后不会返回上一层操作）
优势：非常有利于大型项目中对于人员的管理
不足：前期未发现出的错误可能会导致后期整个项目的失败。由于瀑布模型只有两个阶段（需求分析和运行维护）有用户参与进来，所以使用瀑布模型一定要在需求分析阶段 精准捕获用户的需求。
若不能精准捕获用户的需求，可以使用其他模型：比如，原型化模型、演化模型或增量模型
- 原型化模型是一种“可抛弃模型”，根据捕获的用户需求抛弃掉原型化模型，进行模型的开发
- 而演化模型或增量模型，是用来捕获的用户需求后，在已有的演化模型或增量模型的基础上进行改良的开发模型。
4.V模型 --拔高了测试的地位，如何拔高？
一个阶段，做一个对应的测试计划。
补充：有回归/退化测试
5.喷泉模型 （二次开发模型）
软件开发的阶段，存在迭代机制
强调的是，各个相邻阶段之间的设计没有明显的界限。
优点：提高了开发的效率
缺点：不利于人员的管理。不利于组织和文档的管理。
6.螺旋模型
原型化方法+瀑布模型的组合，主要是加入了“风险分析”这一阶段
原型1+瀑布模型的几个阶段
原型2+瀑布模型的几个阶段
........知道最后形成一个螺旋系统。
3.3软件开发和测试
1.划分软件系统模块遵循原则：高内聚、低耦合
- 高内聚：一个模块内部的各个元素的紧密程度，越紧密越好。
- 低耦合：而模块与模块之间的关系，越松散越好。称为耦合。
2.软件测试类型
- 动态测试：要上机。动态测试又分为以下3种
- 黑盒测试法--只关注输入和输出阶段，过程看做一个黑盒。（比如：边界值分析法）
- 白盒测试法--关心程序内部执行的细节，把程序看做一个透明的盒子。所以白盒测试又称为：逻辑驱动测试、路径测试或结构测试。
- 灰盒测试法--介于两者之间 [渣男]。
既关心黑盒（输输入和输出），又关心白盒（程序内部执行细节），只不过关心程度不及白盒测试。
- 静态测试:不通过计算机。多半是程序员的自查，或者说是程序员的审查。
3.4软件测试（几个阶段） V模型
| 阶段 |
对应测试 |
测试作用（目标） |
| Top 验收测试 |
有效性测试、软件配置审查、验收测试 |
|
| 需求分析 |
系统测试 |
系统测试：主要包括恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试 |
| 概要设计 |
集成测试 |
模块间的接口和通信 |
| 详细设计 |
单元测试 |
模块接口、局部数据结构、边界条件、独立的路径以及错误处理等 |
| 编码 |
