软件过程模型
一. 软件过程
- 软件过程定义内容：人员与分工、所执行的活动、活动的细节和步骤
- 软件过程通过以下方式组织和管理软件生命周期：定义软件生产过程中的活动、定义这些活动的顺序及其关系
- 软件过程的目的：标准化、可预见性、提高开发效率、高质量产品，提升制定时间和预算计划的能力
黑盒测试与白盒测试（后面还会细讲，具体来说白盒测试知道代码怎么写的，可以根据代码来写测试）
软件过程的典型阶段：提出设想
二. 典型软件过程模型
1. 瀑布模型（鲑鱼模型）
一旦向前一阶段就很难回溯
计划
- 上一阶段结束下一阶段才开始，上一阶段的输出是下一阶段的输入
- 每个阶段都有里程碑和提交物，每个阶段均需要进行V&V（verification and validation，验证和确认）
- 侧重于文档和产出物（回溯难）
优点——追求效率
- 按阶段划分检查点，项目易于管理
- 每个阶段必须提交文档，并且每个阶段产品必须进行正式、严格的技术审查
缺点——过于理想化
- 用户需求难以清楚确认，需求变更
- 开发人员与用户缺乏沟通，只依赖文档难以满足客户需求
- 项目接近尾声才得到可执行程序，如果存在缺陷，由于难以回溯，可能造成重大损失
- 也就是说瀑布模型太理想、太单纯，不适用于现代软件开发
适用场合（总体来说，就是要满足顺序开发、尽量不回溯、需求明确等特点）
- 项目小，各模块接口定义清晰
- 产品定义明确，开发中不能有太大的变动
- 开发技术成熟，团队成员都熟悉这些技术
- 各个步骤的子团队分属机构不同或地理位置不同，难以频繁交流
- 外部环境的不可控因素少
2. 增量过程模型
解决的问题：初始需求不明确（只需要需求的核心部分），迫切为用户迅速提供功能有限的软件之后再进行扩充
2.1 增量模型
软件被作为一系列的增量来设计、实现、集成和测试，每一个增量是由多个相互作用的模块所形成的特定功能的代码片段构成
本质：以迭代的方式运行瀑布模型
- 第一个增量往往是核心产品：满足基本需求，但缺少附加特性
- 客户使用上一个增量的提交物进行评价。指定下一个增量的计划（需要增加的特性和功能）
- 重复上述过程
优点
- 时间要求高，短时间交付满足客户需求的一个子集的可运行产品（不要求完整产品）
- 人员分配灵活，开发人员不够，可以采用增量模型
- 逐步增加产品功能，用户有充裕的时间来学习和适应新产品
- 较高优先权的模块首先交付，增量不断集成，重要功能接受更多测试，项目总体失败的风险较低
困难
- 加入增量，不破坏原来已经构造好的部分
- 加入新增量时应简单、方便
- 无法处理需求发生变更（无法变更已经有的需求！！！！）
- 管理人员必须有足够的技术能力来协调好各增量之间的关系
2.2 快速应用程序开发（RAD）
快速开发应用RAD（Rapid Application Development）
侧重于短开发周期，是瀑布模型的高速变体，通过基于构件的构建方法实现
多个团队并行进行开发，先启动的团队的提交物作为后启动团队的输入
缺点
- 大量人力资源来（多个RAD团队）
- 如果没有在短时间内为急速完成整个系统做好准备，RAD项目将会失败
- 如果系统不能被合理的模块化，RAD将会带来很多问题
- 技术风险很高的情况下（采用很多新技术、软件需与其他已有软件建立集成等等），不宜采用RAD
3. 演化过程模型
需要解决的问题：开发过程需求经常变化、交付时间紧张（不可能圆满完成软件产品）、扩展的细节没有定义
演化过程模型的目的：需求的变更频繁，要求在非常短的期限内实现，以充分满足客户/用户要求、及时投入市场
本质：循环、反复、不断调整当前系统以适应需求变化
演化过程的模型的问题：
- 周期数不确定，项目管理困难
- 演化太快——项目混乱，演化太慢——影响生产率
- 为了质量牺牲开发速度、灵活性和可扩展性
3.1 螺旋模型（强调风险）
螺旋式过程模型与增量、AD等的最大区别在于重视风险评估
- 螺旋模型沿着螺旋线在四个象限内表达四个方面的活动
- 制定计划：确定软件目标，弄清方案和限制
- 风险分析：分析所选方案，考虑识别和消除风险
- 实施工程：开发验证
- 客户评估：评价开发、提出修正建议
出发点：开发过程中及时识别和分析风险，并采取适当措施以消除或减少风险带来的危害
优点：结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型
- 循环逐步加深系统定义和实现程度，更好理解、应对和降低风险
- 确定一系列里程碑
- 保持可操作性，直到软件生命周期结束
- 风险驱动，支持现有软件复用
缺陷：
- 适用于大规模、内部项目，周期长、成本高
- 寻找可能风险，否则带来的风险更大
3.2 原型模型（快速原型法）
Step 1：双方通过沟通，明确已知的需求，并大致勾画出以后再进一步定义的东西
Step 2：迅速策划一个原型开发迭代并进行建模，主要集中于那些最终用户所能够看到的内容，如人机接口布局或者输出显示格式等
Step 3：快速设计产生原型，对原型进行部署，由客户和用户进行评价
Step 4：根据反馈，进一步细化需求并调整原型
Step 5：原型系统不断调整以逼近用户需求
原型类型：
- 抛弃型原型：原型不可执行，得到认可之后不作为系统一部分而是被抛弃，目的只是收集和验证客户需求
- 演化式模型：原型可执行，是系统的一部分，最初构造的原型将具备较高的质量，包含了系统的核心功能，然后通过收集需求对其进行不断的改善和精化
优点：提高和改善客户/用户的参与程度，最大程度的响应用户需求的变化
缺点：
- 为了尽快完成原型，开发者没有考虑整体软件的质量和长期的可维护性，系统结构通常较差
- 可能混淆原型系统与最终系统，原型系统在完全满足用户需求之后可能会被直接交付给客户使用（演化式模型）
- 额外的开发费用（一般是抛弃式模型）
4. 其他过程模型
4.1 形式化过程
严格的数学形式刻画每一阶段（需求、设计、程序、测试）
形式化方法在各阶段产物间进行自动化/半自动的转换
优点：提供无缺陷的软件
缺陷：难以理解，可视性差，技术要求高；耗时、耗成本；有些方面难以形式化表达（太过理想化，实践很少用）
应用：可靠性和安全性要求较高的系统
4.2 软件复用过程
主要思想：复用
新软件系统，通过已有的软件单元（软构件）来构造系统
过程：需求分析