2.1 软件过程的概念

2.1.1 软件生命期概念

• 软件生命周期的概念：软件产品或软件系统从设计、投入使用到被淘汰的全过程

• 主要包含如下几个过程：
1. 问题定义
2. 可行性分析
3. 需求分析
4. 总体设计
5. 详细设计
6. 编码
7. 测试
8. 维护

2.1.2 软件过程概念

• 软件过程的概念：软件过程是在软件产品构建过程中，所需完成的活动、动作和任务的集合（就是在构建软件工程产品时需要做的事）
• 活动：主要关注宽泛的目标
• 动作：包含了主要软件产品生产过程中的一系列任务
• 任务：关注小而明确的目标，能够产生实际产品

2.1.3 软件过程模型概念

• 软件过程模型的概念：是软件开发全部过程、活动、动作和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。（软件过程模型又被称为：1、软件开发模型 2、软件生存周期模型 3、软件工程范型）

2.1.4 软件过程评估

• 能力成熟度模型（是用来评估一个软件过程是好是坏的）
• 为评估软件组织的开发能力提供了标准
• 为提高软件组织的开发能力指明了方向

2.2 常见软件过程模型

2.2.1 瀑布模型和V模型

• 瀑布模型：规定了各项软件工程活动，以及它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落
• 瀑布模型的特点
• 软件开发过程与软件生命周期一致（按照问题定义、需求分析、设计、构建、测试、维护的顺序进行）
• 是一种使用广泛，以文档为驱动的模型（每个阶段结束前完成文档审查，及早改正错。这就使得每个阶段都需要写文档，这样每个阶段就都有里程碑和响应的产品了）
• 是一种线性模型，阶段间具有顺序性和依赖性
• 常被用来规范软件开发活动
• 注意：实际的瀑布模型是带反馈的
• 当后面阶段发现前面阶段的错误，则沿反馈线返回并修正（只能向上一个阶段反馈错误）
• 对软件的维护，则反馈到相应的阶段（就是可以跨阶段）
• 瀑布模型的缺点
• 增加工作量：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
• 开发风险大：由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险
• 早期错误发现晚：早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
• 不适应需求变化：不能反映实际的开发方式，软件开发需要迭代；无法适应需求不明确和需求的变化
• 瀑布模型的适用场合：瀑布模型适用于系统需求明确且稳定（防止出现需求变化带来严重后果）、技术成熟、工程管理较严格的场合，如军工、航天、医疗

• V模型（是瀑布模型的一个变种）

• 如下图（V模型就是将后面的测试阶段跟前面的分析阶段通过反馈线对应起来，如果在后面的测试阶段发现问题就回到该测试阶段对应的分析阶段，然后重新进行一遍）：



注意：上面说的是重新进行一遍。如若验收测试阶段出现问题，就需要回到需求分析阶段重新确认需求，然后重新走总体设计、详细设计、编码、单元测试、系统测试等阶段，最终重新回到验收测试阶段

2.2.2 原型和增量模型

• 原型模型
• 原型：一个部分开发的产品，使客户和开发人员能够对计划开发的系统的相关方面进行检查
• 原型的结果（原型不一定就是最终产品的一部分）
• 抛弃原型
• 把原型发展成最终产品
• 原型化的目的
• 快速明确并完善需求，如演示原型（让用户看看是不是这样做。可以说原型是在需求分析阶段使用的）
• 研究技术选择方案，如技术验证原型
• 原型模型的优缺点
• 优点：减少需求不明确带来的风险（上面说的原型化的目的之一就是能够明确需求）
• 缺点：构造原型采用的技术和工具不一定主流；快速建立起来的系统加上连续的修改可能导致原型质量低下，设计者只能在质量和原型中进行折中；客户意识不到一些质量问题
• 原型模型使用的场合：客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式（说白了就是需求不清晰的时候就做一个原型看看效果）

• 增量模型

• 摆一张增量模型的图便于理解：



• 增量的定义：满足用户需求的一个子集，能够完成一定功能、小而可用的软件（有点像原型）
• 增量方式与迭代方式（实际使用中，常常是两种方式的结合）
• 增量方式就是不断增加新功能（这些功能是前一个发布没有的）
• 迭代方式就是不断改进功能（这些功能是之前的发布已经有的）
• 增量模型的特点
• 增量模型是一种非整体开发的模型，是一种进化式（增量模型就是在不断更新进化）的开发过程
• 增量模型从部分需求出发，先建立一个不完整的系统（就是做一个增量出来），通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善
• 如此反复进行，直至软件人员和用户对所设计的软件系统满意为止
• 增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间（若干个发布是按照时间顺序的）的线性序列，每个线性序列（线性序列就是指上面图片中的一行）都会输出该软件的一个“增量”
• 每个增量的开发可用瀑布或快速原型模型（所以可以发现实际上每一个增量就是一个被发展成最终产品部分的一个原型）
• 增量模型的优点
• 增量概念的引入，不需要提供完整的需求，只要有一个增量出现，开发就可以进行（开发速度快）；软件能够更早投入市场（开发出一个增量就可以投入市场了）
• 开放式体系结构，便于维护（开放式体系结构就是说软件产品的功能之间是比较独立的，一个功能增量开发错误对其他增量的影响小，这样就便于维护了）
• 在项目的初始阶段不需要投入太多的人力资源（因为只是开发一个增量，不需要那么多人）
• 产品逐步交付，软件开发能够较好地适应需求的变化；能够看到软件中间产品（有点像原型），提出改进意见，减少返工，降低开发风险
• 增量模型的缺点
• 每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量（也就是开发人员不好确定增量的大小）
• 软件必须具备开放式体系结构（要求软件的功能之间关联较低）
• 易退化成边做边改（在做一个增量的时候可能还需要修改上一个增量的问题）的方式，使软件过程控制失去整体性
• 增量模型的适用场合：适用于软件开发中需求可能发生变化（因为增量模型能够较好地适应需求变化）、具有较大风险（能够看见中间产品，进而提出改进意见减少返工降低风险）、或者希望尽早进入市场的项目（有一个增量就可以进行开发，然后投入市场）

2.2.3 螺旋模型和喷泉模型

• 螺旋模型：软件开发过程中普遍存在风险，所以把开发活动和风险管理结合起来控制风险（所以螺旋模型适合风险较高的场合）
• 螺旋模型的开发过程：开发过程分成若干次迭代，每次迭代代表开发的一个阶段，对应模型中一条环线每次迭代分成四个方面的活动
• 明确目标，选定方案，弄清项目开发的限制条件
• 评估所选方案，通过构造原型和风险分析识别和消除风险
• 实施软件开发和验证
• 评价本阶段，计划下一阶段
• 模型结合了瀑布模型（每一圈对应一个阶段，阶段之间的次序是线性固定的）和原型模型（每一个阶段都会做一个原型出来）的特点
• 螺旋模型的优点
• 螺旋模型强调原型（在开发过程中使用了原型）可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力，支持用户需求的动态变化
• 螺旋模型中每一个阶段产生的原型可看作可执行的需求规格说明，易于为用户和开发人员共同理解（这就是原型的特点了），还可作为继续开发的基础，并为用户参与所有关键决策提供了方便（用户只能看懂原型）
• 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险
• 螺旋模型的缺点
• 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟交付时间
• 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高，否则会带来更大风险（需要能够正确评估风险，错误评估风险只会带来更大的风险）
• 螺旋模型的适用场合：适用于需求不明确或者需求可能发生变化（通过原型的特点解决）的大型复杂的软件系统（通过瀑布模型的特点解决）

• 喷泉模型
• 喷泉模型的特点
• 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程
• 软件开发早期定义对象，整个开发过程扩充对象
• 各个阶段使用统一的概念和表示方法，生命周期各阶段无缝连接
• 各个开发步骤多次反复迭代（跟螺旋模型一样需要迭代，但是螺旋模型是一个阶段一个迭代，而喷泉模型是一个阶段多次迭代）
• 喷泉模型的优点：喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发（比如需求分析和编码和设计就可以同时开始做），可以提高软件项目开发效率，节省开发时间
• 喷泉模型的缺点
• 由于喷泉模型在各个开发阶段是重叠的（各个阶段的人员需要同时参与），在开发过程中需要大量的开发人员，因此不利于项目的管理
• 喷泉模型要求严格管理文档（记忆：跟水有关系的都需要严格管理文档），使得审核的难度加大，尤其是面对可能随时加入的各种信息、需求与资料的情况
• 喷泉模型的适用场合：适用于面向对象开发

2.2.4 基于构件的开发模型

• 基于构件的开发模型的焦点：考虑的焦点是集成（也就是如何把各个部件拼在一起），而非实现

• 构件/组件的特点
• 系统中模块化的、可更换的部分
• 实现特定的功能
• 对实现进行封装，暴露一组接口

• 基于构件的开发模型的阶段
• 需求分析
• 构件分析（根据需求选取构件）
• 系统设计（分析构件是否能重用和集成）
• 开发集成（将构件集成到系统中）

• 基于构件的开发模型的优点
• 软件复用思想；降低开发成本和风险（因为用的构件都是可靠的），加快开发进度，提高软件质量

• 基于构件的开发模型的缺点
• 模型复杂商业构件不能修改，会导致修改需求，进而导致系统不能完全符合客户需求
• 无法完全控制所开发系统的演化（因为都是一个一个构件往上加的，可能很快；也可能存在找不到构建的情况，这个时候开发就很慢）
• 项目划分的好坏（决定了构件的选取）直接影响项目结果的好坏

• 基于构件的开发模型的适用场合：适用于系统之间有共性的情况（这样就可以重用构件了）

2.2.5 统一开发模型

• 统一过程模型从哪些视角描述软件开发过程（ppt上有对这三个视角的详细介绍）
• 动态视角：随时间变化的各个阶段
• 静态视角：所进行的活动（活动，或者说大目标是确定的）
• 实践视角：可采用的良好实践建议

• 统一过程模型的适用场合：适合大团队大项目

2.2.6 敏捷开发过程（敏捷模型）

• 敏捷软件开发宣言
• 个体交互：个体和交互胜过过程和工具
• 可工作软件：可以工作的软件胜过面面俱到的文档
• 客户合作：客户合作胜过合同谈判
• 相应变化：响应变化胜过遵循计划

• 敏捷软件开发：敏捷软件过程是基本原理和开发准则的结合
• 基本原理
1. 小但有激情的团队（就是想加班是吧。是在开发过程中）
2. 非正式的方法（在开发过程中）
3. 最小的软件工程产品（项目结果）
4. 客户满意度和较早的软件增量交付（项目结果）
5. 简化整体开发（整体）
• 开发准则
• 超越分析和设计的交付
• 开发者和客户之间积极持续的交流

• 敏捷软件开发实例
• 极限编程：把好的开发实践运用到极致

• 敏捷开发的优点
• 快速响应变化和不确定性（强调跟用户的沟通，就能够快速响应变化）
• 可持续开发速度（强调速度）
• 适应商业竞争环境下的有限资源和有限时间（有限时间，说白了就是开发的快）

• 敏捷开发的缺点
• 测试驱动开发可能导致通过测试但非用户期望
• 重构（光速做一个出来然后不太符合用户需求的时候就需要重新做了）而不降低质量是十分困难的

• 敏捷开发的适用场景：适用于需求模糊且经常改变（通过敏捷开发中的开发人员和客户保持交流解决）的场合，适合商业竞争环境（开发速度快）下的项目。

2.3 软件过程模型选择

• 如何选择软件过程模型
• 前期需求明确的情况下，尽量采用瀑布模型（因为需求变化对瀑布模型的影响很大）
• 用户无系统使用经验（这个时候就做一个原型出来给用户看），需求分析人员技能不足的情况下，尽量借助原型模型
• 不确定因素很多，很多东西无法提前计划（这个时候就先做确定的东西，也就是增量；很多东西无法提前计划，就是风险比较高，所以选择螺旋模型，同时螺旋模型也强调原型的特点，一定程度上是比较像增量模型的）的情况下，尽量采用增量模型或螺旋模型
• 需求不稳定的情况下（这个时候也是先做确定的需求），尽量采用增量模型
• 资金和成本无法一次到位的情况下（增量模型的前期开发人员少），可采用增量模型
• 对于完成多个独立功能开发的情况（软件产品具有开放式体系结构，可以采用增量模型开发），可在需求分析阶段就进行功能并行，每个功能内部都尽量遵循瀑布模型（每一个增量的开发都使用瀑布模型或者快速原型模型）
• 全新系统的开发必须在总体设计（因为是新系统所以需要全部重新设计一遍）完成后再开始增量或并行
• 编码人员经验较少的情况下，尽量不要采用敏捷（强压之下技术就很重要）或迭代模型（也就是螺旋模型。螺旋模型要求有丰富的风险评估知识）
• 增量、迭代（螺旋模型就是一中迭代）和原型可以综合使用，但每一次增量或迭代都必须有明确的交付（也就是每一次增量或者迭代都必须有一个可使用的产品）和出口原则