一、背景知识：
软件开发的基本过程：
需求定义→软件设计→软件实现→软件测试→软件维护
软件的定义：
软件=程序+数据+文档
程序：可以按照设计好的功能和性能要求执行的指令序列
数据：程序能正确处理信息的数据结构
文档：与程序的开发、维护、使用有关的图文资料
软件的特点：
- 包含个人因素的大规模知识型工作
- 有工具辅助的软件开发也尚未实现自动化（即无法像硬件加工一样，机械组装已有部件，软件开发还未达到组装已有模块的程度）
- 对开发和运行的计算机软硬件环境具有依赖性
- 需求往往在变更，开发进度难估算
- 软件测试困难，覆盖所有路径的测试难实现。软件测试只能证明软件中有缺陷，不能证明软件中没有缺陷。
- 软件不会损耗，（参考硬件的磨损和老化），软件维护不再具有经济性时，软件即被淘汰
软件危机：
- 1965年——1985年，20世纪60——80年代
- 于1968年提出
- 催生了软件工程这一学科
- 没有化解软件危机的灵丹妙药，已知的技术和方法都是进一步改进
SWEBOK（软件工程知识体系指南）
PDCA环（戴明环）：
二、软件过程：
以质量为中心，以软件工程，方法，工具为三要素。其中软件过程是基础，是联系各层的桥梁，工具为过程和方法提供支持。
软件过程的定义：软件过程定义了软件开发中的一系列活动，所以过程都具有下列活动：
- 沟通
- 建模
- 计划
- 构造
- 部署
- 项目管理（贯穿于以上所有活动）
软件生命周期：
- 定义时期：问题定义，可行性研究，需求分析
- 开发时期：概要设计，详细设计，编码，测试
- 运行/维护时期
软件过程模型：
- 模型不是过程的直接描述，而是过程的抽象。可以用于解释软件产品不同的开发方法。
- 从项目需求定义到运行维护为止，跨越整个生命周期的过程，活动和任务的结构框架。
- 也被称为：软件生命周期模型，软件开发模型，软件工程范型
瀑布模型：
- 20世纪80年代之前被广泛使用，因此被称为经典的生命周期模型。
- 线性模型：软件开发过程与生命周期是一致的，规定了各项工程活动的自上而下，逐级下落的次序。
- 以文档为驱动
传统的瀑布模型：
- 各个阶段都按顺序执行
- 每个阶段完成规定的文档
- 每个阶段结束有一个验证环节，只有通过验证才能进入下一个阶段
- 阶段间具有顺序性和依赖性：前一阶段的输出文档就是后一阶段的输入文档
- 推迟实现的观点（重要思想）：区分开逻辑设计和物理设计，推迟程序的物理实现
- 质量保证的观点：每个阶段必须完成规定的文档，并在阶段结束前进行审核
实际的（带反馈的）瀑布模型：
若后面的阶段发现前面阶段的错误，则返回前面阶段进行修改。
瀑布模型的优缺点：
- 每个阶段交出的作品都是经过验证的，每个阶段都有文档
- 能较好的与其它过程模型结合
- 不够灵活：下一阶段开始前，当前阶段的结果需固定下来
- 整体性太强：分析阶段出现任何失误，交互用户后才能发现，增加了开发的风险
- 严格文档驱动，较为繁琐
- 开发早期投入大量成本，难以应对用户需求变更
瀑布模型适用于：需求很明确且将来没有太大改变的情况。大型项目中一些部分的开发。
演化模型（分为原型模型和并行开发模型）：
首先实现软件最核心，最重要的功能，待用户进一步了解软件后再实现细节。
相比瀑布模型能更高效地生产出符合要求的系统，灵活面对客户需求变更。
小型和中型系统：演化模型
大型系统：混合瀑布模型和演化模型（采用演化模型难以建立稳定的系统架构，不利于团队工作整合）
原型模型：
快速建立起可以在计算机上运行的程序，是最终产品的子集。
与用户确定下原型以后，再开始完整的开发过程。
原型确定后，下面的开发过程基本不带反馈。
原型模型的优缺点：
-
- 有助于了解用户的真正需求
- 不会因为需求规格说明文档的错误进行大规模返工
- 开发人员在实现原型系统学到了东西，后续出错率降低
- 为了快速开发出原型，开发人员可能不会长远考虑，而降低质量，放弃部分需求
并行开发模型（并发模型）：
所有活动同时存在但是处于不同状态。
增量过程模型（分为增量模型，RAD模型，螺旋模型）：
非整体开发的模型，从部分需求出发，建立一个不完整的系统——测试——添加增量。
增量模型：
增量：小而可用的软件
- 增量模型与原型模型的不同在于：每个增量都是可运行的产品，能完成特定功能。
- 每个增量的开发可以采用瀑布模型或快速原型模型。
- 第一个增量通常是核心产品。
- 在前面增量的基础上开发后面的增量。
- 一个增量部署后，进入下一次迭代，直到出现最终产品。
- XP极限编程：基于小增量的开发和交付
增量模型的优缺点：
- 无需完整需求，只要一个增量包，开发即可进行。
- 项目初始阶段无需大量人力资源，被认可后才投入。
- 不能在ddl前完成项目，核心增量产品也能交付。
- 很难根据需求给出大小合适的增量。
- 加入新增量不能破坏已开发出的产品。
- 需要比瀑布和原型模型更精心的设计。
RAD（Rapid Application Development）快速应用开发模型：
- 强调短暂的开发周期，瀑布模型的“高速”变体
- 主要用于信息系统的开发
- 包括业务建模，数据建模，过程建模
- 需要足够的人力资源
- 并非所有系统都适合，不能合理模块化和技术风险高的系统都不适合
螺旋模型：
结合了瀑布模型和原型模型，加入了两种模型都没有的风险分析。
强调风险管理：适用于大型系统的开发。
基本思想：使用原型及其它方法来尽量降低风险。
理解为：在每个阶段都加入风险分析的快速原型模型
特点：
- 能应对开发过程中的各种变化。
- 仅适用于内部项目，不能用于合同性的软件开发，因为过程中有风险评估。
- 风险驱动：要求开发人员具有丰富的风险评估经验和专业知识。
- 只适用于大型软件的开发。
基于构件的模型：
- 构件（也称组件）：支持软件重用（复用）Software Reuse
- 以重用为导向，以大量可用的组件及一些集成框架为基础。
- 根据需求规格搜索可重用的组件，通常情况下没有，则对组件加以修改或构造新的组件，再将组件进行开发和集成。
敏捷过程模型：
基本原理和开发过程的结合。
如何选择过程模型？
- 各种过程模型并不互相排斥，在开发中通常一起使用。
- 软件过程决定了软件产品的质量。
- 可根据实际创造新的模型。
软件开发中的两种倾向：以产品为中心/以过程为中心（以过程为中心更能生产高质量的产品）
能力成熟度模型：
软件过程成熟度：1.角色与职责 2.处理变更的方式 3.对发生问题的反应 4.可信性 5.对工作人员的奖励 6.预见性
CMM(Capibility Maturity Model)：能力成熟度模型：
- 最早提出时，它指的是软件过程能力成熟度模型。
- 按照成熟度划分为5个等级。1级最低，5级最高。
SEI(Software Engineering Institute)：软件工程研究所（发布CMM，CMMI）
CMMI(Capibility Maturity Model Integration)：能力成熟度模型集成
CMMI 1.2：当前实施的有效版本
- 将成熟度分为5个等级，只有达到某个等级后，才能进入下一等级。
- 只定义要达到什么目标，不定义如何达到。
- 初始级：依赖于有能力的人
- 可重复级：有基本的项目管理
- 已定义级：过程标准化
- 量化管理级：收集分析数据，来支持决策。制定量化目标，以此作为管理过程的标准
- 优化级：持续地改进过程
过程域（Process Area PA）:
CMMI每个等级都规定了过程域。即若干个值得重视的软件过程。