【软件工程】第二章 软件生命周期模型

这章简单介绍了10个传统的模型和2个新型的模型

10个传统模型

一、瀑布模型

优点

1. 第一次把生命周期模型过程结构化，透明化，便于管理
2. 强调需求分析和设计的重要性，必须完成这两部分才能进行编码
3. 以项目的阶段评审和文档严格的控制和指导了整个过程，能够及时发现问题，控制了质量

缺点

1. 因为是串行的过程，所以如果一开始需求没法固化，甚至需求提不出来，无法进行下面的步骤
2. 编码步骤太靠后，成品时间长，如果到了编码部分才发现问题，按照瀑布模型的原则需要推倒从头来，耗费时间
3. 管理人员容易被蒙蔽，因为管理人员决定推进到下一步的依据是文档

二、V模型

相比瀑布模型更强调测试，把测试广义化了

单元测试-->组装测试-->系统测试-->验收测试

组装测试和系统测试区别：组装测试是简单的集成之后的测试，系统测试是看软件在客户的环境中有没有问题

问题：测试还是在代码写完之后进行

三、W模型

两个v模型，测试和瀑布模型这两个v并行    

 问题：还是没有解决需求不明确的问题

四、原型方法

就是为了解决上面这个问题，先做一个原型出来，让用户评价。这是一种思想，不是具体的模型

获得基本需求-->做个原型-->让用户使用-->用户评价-->改进-->新的原型-->周而复始

原型的种类

1. 探索性：目的是弄清需求，弄清需求之后就可以按瀑布模型做了
2. 实验性：目的是考察可行性
3. 进化型：不丢弃原型，将原型开发到实现所有功能

原型方法可以用于瀑布模型的任一阶段

优点：

1. 增进对需求的理解
2. 对于用户来说是种学习使用软件的手段
3. 容易确定系统的性能，服务的可应用性，设计的可行性，产品的结果
4. 原型可以作为最终版本的一部分

缺点

1. 文档容易被忽略
2. 如果是探索或实验性原型，最后会被扔掉
3. 难以规划和管理

五、演化模型

以原型方法这种思想得到的生命周期模型

分两次，第一次试验开发，然后给用户用，评价，（如果需求还是不明确，就再来一次，直到明确），第二次产品开发

缺点：

1. 第一次不是瀑布式开发，所以瀑布模型的优点都没了，开发过程不透明
2. 可能会导致系统结构发生变化（这是最大的缺点）（那只要需求会变，那不就有可能发生变化吗，对比敏捷，敏捷不也是这样吗）
3. 为了实现快速开发的目的，程序员可能会用到一些不符合主流、不符合要求、不程序的工具和技术

六、增量模型

也是原型方法的一种实践，结合了瀑布模型和演化模型的优点

确定需求-->设计系统体系结构-->增量开发-->给用户用，反馈-->…-->用户测试，提交

与演化模型最大的不同，是必须保证系统体系结构不能变

优点

1. 增强了客户使用系统的信心，让用户更好的提出需求
2. 失败的风险低
3. 因为增量优先级的原因，最早做的是最核心的，每次增量都会被测试，所以最核心的功能会测试很多次
4. 体系结构不变，稳定，可维护性高

缺点：

1. 难以确定基本的功能
2. 增量增多少不好确定，增量的粒度

七、螺旋模型

本质上也是原型方法的实践

 

制定计划-->风险评估-->实施工程-->客户评估-->……-->循环

每一圈都是瀑布模型的一个步骤，相当于就是在瀑布模型的每一个步骤上应用了原型，并且进行风险分析，风险分析是螺旋模型的最大特点

八、喷泉模型（迭代模型）

 喷泉模型认为软件开发是

1. 迭代的
2. 各阶段不是完全串行的，不是说例如需求分析没完成就不能进行编码，可以进行一部分分析，就去设计，是无间隙的；对于面向对象的开发来说，设计的结果可以复用，例如需求中的对象分析可以直接复用在设计中的对象，所以天然适配面向对象，不适配结构化编程

九、构建组装模型

适用于非常标准化的领域

这样软件开发阶段就可以用可复用的构件库中找组件组装软件。

十、RAD模型，基于构建组装模型，理想的开发模型

把大型软件拆成多个功能独立的小软件，每个小软件采取构建组装模型

新型模型

认为人是重要的，认为人要交流

一、统一软件开发过程（rational unified process）

也是原型方法的实践，不同的地方引入了三个核心支持工作流，核心过程工作流和瀑布模型是基本一致的

融合了喷泉模型（迭代）和增量模型

核心支持工作流

1. 配置和变更管理：比如版本管理，工具git
2. 项目管理：是管理人、财物，是管理学的内容；RUP有软件可以给算，给人、项目时间之类的输入，他可以给输出方案
3. 环境：编辑器啥的

二、敏捷开发

是个思想

敏捷宣言

怎么能在响应变化的情况下保证开发的流畅性和系统体系结构的不变呢

极限编程，基于敏捷思想的一个开发方法

 

同一个工作环境，站立会议，不提倡加班，大白板（user story）

需求分析  用户故事

编程 结伴编程，团队代码所有制

测试 写程序之前先写测试，有了用户故事就出测试用例