软件工程02：软件生命周期模型
1. 工程过程
工程项目的三个基本目标：合理的进度、有限的经费、一定的质量。
对于质量目标，提出戴明环：Plan -> Do -> Check -> Act -> Plan -> ...
2. 软件工程过程
定义：是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。
主要活动有：
(1). 软件规格说明：规定软件的功能及其使用限制；
(2). 软件开发：产生满足规格说明的软件；
(3). 软件确认：通过有效性验证以保证软件能够满足客户的要求；
(4). 软件演进：为了满足客户的变更要求，软件必须在使用过程中进行不断地改进。
3. 软件生命周期
定义：指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交和运行阶段等不同时期。
六个基本步骤：制定计划、需求分析、设计、程序编码、测试、运行维护。
设计：概要设计、详细设计。
测试：单元测试、组装测试。
运行维护：改正性维护、适应性维护、完善性维护。
4. 软件生命周期模型
软件过程模型：从一个特定角度提出的对软件过程的概括描述，是对软件开发实际过程的抽象，包括构成软件过程的各种活动、软件工件以及参与角色等。
软件生命周期模型是一个框架，描述从软件需求定义直至软件经使用后废弃为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等。
4.1. 瀑布模型
瀑布模型为软件开发和软件维护提供了一种有效的管理模式，它在软件开发早期为消除非结构化软件、降低软件复杂度、促进软件开发工程化方面起着显著的作用。
特征：
(1). 本活动的工作对象来自于上一项活动的输出，这些输出一般是代表该阶段活动结束的里程碑式的文档。
(2). 根据本阶段的活动规程执行相应的任务。
(3). 产生本阶段活动相关产出—软件工件，作为下一活动的输入。
(4). 对本阶段活动执行情况进行评审。
4.2. 演化模型
第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求；
第二次在此基础上获得较为满意的软件产品。
优点：明确用户需求、提高系统质量、降低开发风险。
缺点：
(1).难于管理、结构较差、技术不成熟；
(2).可能会抛弃瀑布模型的文档控制优点；
(3).可能会导致最后的软件系统的系统结构较差 ；
适用范围：需求不清楚、小型或中小型系统、开发周期短。
4.3. 增量模型
首先对系统最核心或最清晰的需求进行分析、设计、实现、测试并集成到系统中，再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法。结合了瀑布模型和演化模型的优点。
优点：
(1).客户可以在第一次增量后就使用到系统的核心功能，增强了客户使用系统的信心；
(2).项目总体失败的风险较低，因为核心功能先开发出来，即使某一次增量失败，核心功能的产品客户仍然可以使用。
(3).由于增量是按照从高到低的优先级确定的，最高优先级的功能得到最多次的测试，保障了系统重要功能部分的可靠性。
(4).所有增量都是在同一个体系结构指导下进行集成的，提高了系统的稳定性和可维护性。
缺点：
(1).增量粒度难以选择；
(2).确定所有的基本业务服务比较困难。
4.4. 喷泉模型
也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。各个开发阶段没有特定的次序要求，完全可以并行进行。
优点：提高开发效率、缩短开发周期。
缺点：难于管理。
4.5. V模型和W模型
将测试活动提前，使得瀑布模型能够驾驭风险。
4.6. 螺旋模型
主要针对大型软件项目的开发周期长、风险高的特点。
四个象限：制定计划、风险分析、实施工程、客户评价。
4.7. 原型方法
原型：模拟某种最终产品的原始模型。
原型方法：在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。主要用于明确需求，但也可以用于软件开发的其他阶段。
种类：
(1). 废弃策略（探索型、实验型）
(2). 追加策略（进化型）
适用局限性：
(1). 大型系统
(2). 大量运算、逻辑性较强的程序模块
(3). 原有应用的业务流程、信息流程混乱的情况
存在的问题：
(1). 文档容易被忽略
(2). 建立原型的许多工作会被浪费
(3). 项目难以规划和管理
4.8. RUP
定义：一种软件工程过程框架，是一个基于面向对象的程序开发方法论。
敏捷模型：是归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它是快速软件开发的一种思想代表。
四个顺序阶段：初始阶段、细化阶段、构造阶段、交付阶段。
每个阶段结束于一个主要的里程碑，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
4.8.1. 初始阶段
目标：通过业务场景了解业务并确定项目的边界。包括项目的验收规范、风险评估、所需资源估计、阶段计划等。
要确定项目边界，需识别所有与系统交互的外部实体，主要包括识别外部角色、识别所有用例并详细描述一些重要的用例。
里程碑：软件目标里程碑。包括一些重要的文档（远景。用例模型、风险评估等）。
4.8.2. 细化阶段
目标：分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高、风险大的关键需求的开发。
里程碑：体系结构里程碑。包括一些重要的文档（风险分析。软件体系结构基线等）。
4.8.3. 构造阶段
目标：将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。
里程碑：运行能力里程碑。包括可运行的软件产品、用户手册等。
4.8.4. 移交阶段
重点：确保软件对最终用户是可用的。
可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。
里程碑：产品发布里程碑。要确定最终目标是否实现。
RUP的特点：以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型。
核心活动：
6个核心过程工作流：业务建模、需求、分析和设计、实现、测试、部署。
3个核心支持工作流：配置和变更管理、项目管理、环境。
最佳实践，适应性开发：小步骤、快速反馈和调整。
4.9. 极限编程
XP是一种轻量级的软件开发方法，是一种以实践为基础的软件工程过程和思想。
它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。
XP强调用户满意，开发人员可以对需求的变化作出快速的反应。
4.10. 构建组装模型
利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的。
优点：
(1). 充分利用软件复用，提高了软件开发的效率。
(2). 允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。
缺点：
(1). 缺乏通用的构件组装结构标准，风险较大；
(2). 构件可重用性和系统高效性之间不易协调；
(3). 由于过分依赖于构件，构件质量影响着最终产品的质量。
4.11. 快速应用开发模型（RAD）
是一个增量型的软件开发过程模型，强调极短的开发周期。
缺点：
(1). 并非所有应用都适合采用RAD
(2). 由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败
(3). RAD适合于管理信息系统的开发，对于其他类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适
