1.软件生存周期模型是指一个包括软件产品开发、运行和维护有关过程、活动和任务的框架，其中这些过程、活动和任务覆盖了从该系统的需求定义到系统的使用终止。P53
2.所有模型的内在基本特征.P53
- 描述了开发的主要阶段
- 定义了每一个阶段要完成的主要过程和活动
- 规范了每一个阶段的输入和输出（提交物）
- 提供了一个框架，可以把必要的活动映射到该框架中
3.传统软件工程过程模型的主要代表是编码修正模型、瀑布模型、增量模型、演化模型和螺旋模型。IBM公司的统一过程(简称RUP)、敏捷过程(AP)和微软解决方案(MSF)等则是现代软件工程模型的主要代表。P53
4.编码修正模型是所有模型中最为古老的也是最简单的模型，该模型将软件开发分为编码和测试两个活动。该模型特点如下:P54
- 最适用于很小且简单的项目
- 成本可能很低
- 易于使用，人员只需要很少的专业知识，任何写过程序的人都可以使用
- 对于一些非常小的、开发完后就会很快丢弃的软件可以采用
- 对于规模稍大的项目，采用这种模型是很危险的。由于缺乏预先的计划并且通常伴随着不正规的开发方式，容易导致代码碎片，交付的产品重量也很难保证。且因为设计没有很好地文档化，因此代码维护困难。
5.瀑布模型是典型的软/硬件开发模型。包括需求、设计、编码、测试、运行与维护几个阶段。每一个阶段交付产品为：软件需求规格说明书、系统设计说明书、实际代码和测试用例、最终产品、产品升级等。该模型主要特点如下：P54~P55
- 每一阶段都以验证/确认活动作为结束，其目的是尽可能多地消除本阶段产品中存在的问题。
- 在随后的阶段里，尽可能对前面阶段的产品进行迭代。
6.瀑布模型的优缺点。P55
优点：
- 容易理解、管理成本低。
- 它不提供有形的软件成果，除非到生存周期结束时。但文档产生并提供了贯穿生命期的进展过程的充分说明。允许基线和配置早期接受控制。前一步作为下一步被认可的、文档化的基线。
缺点：
- 客户必须能够完整、正确和清晰地表达其需要。但在系统开发中经常发现用户与开发人员沟通存在巨大差异、用户提出含糊需求又被开发人员随意解释，以及用户需求会随着时间推移不断变化等问题。
- 可能要花费更多的时间来建立一些用处不大的文档。
- 在开始的两个或者三个阶段，很难评估真正的进度状态。
- 在一个项目的早期阶段，过分强调了基线和里程碑处的文档。
- 开发人员一开始就必须理解其应用。
- 当接近项目结束时，出现了大量的集成和测试工作。
- 直到项目结束之前，都不能演示系统的能力。
7.V 模型是瀑布模型的一个变形，它在每一个环节都强调了测试，同时又在每一个环节都做到了对实现者和测试者的分离。V模型被广泛应用于软件外包中。
8.增量模型（增量生存周期模型）是由瀑布模型演变而来的，它是对瀑布模型的精化。该模型有一个假设，即需求可以分段，成为一系列增量产品，对每一增量可以分别地开发。在开始开发时，需求就很明确，并且产品还可以被适当地分解为一些独立的、可交付的软件，成为构造增量。在开发中，期望尽快交付其中的一些增量产品。P57~P58
9.增量模型的优缺点。P59
优点：
- 第一个可交付版本所需要的成本和时间是很少的。
- 开发由增量表示的小系统所承担的风险是不大的。
- 由于很快发布了第一个版本，因此可以减少用户需求的变更。
- 允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。
缺点：
- 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。
- 如果需求不像早起考虑到的那样稳定和完整，那么一些增量就可能需要重新开发、重新发布。
- 管理发生的成本、进度和配置的复杂性，可能会超出组织的能力。
10.演化模型显式地把增量模型扩展到需求阶段。为了第二个构造增量，使用了第一个构造增量来精化需求。
11.演化模型的优缺点。P60
优点：
- 在需求不能予以规范时，可以使用这一演化模型。
- 用户可以通过运行系统的实践，对需求进行改进。
- 与瀑布模型相比，需要更多用户/获取方的参与。
缺点：
- 演化模型的使用仍然处于初步探索阶段，因此具有较大的风险，需要有效的管理。
- 该方法的使用很容易成为不编写需求或设计文档的接口，即使需求或实际可以很清晰的描述。
- 用户/获取方不理解方法的自然属性，因此当结果不够理想时，可能产生抱怨。
12.螺旋模型中开发工作是迭代进行的，即只要完成了开发的一个迭代过程，另一个迭代过程就开始了。P60
13.螺旋模型最重要的优势是随着成本的增加，风险程度随之降低。时间和资金花的越多，风险越小，这恰好是在快速开发项目中所需要的。P62
14.构造原型的目的。P62
- 开发需求，具备完备功能的、可交付的、可支持的增量的实现就是基于这些需求。包括功能需求和界面需求。
- 用于为一个项目或一个项目的某些部分确定技术、成本和进度可行性。
15.使用商业应用框架和商业组件，或复用组织内部已开发的组件和框架。该趋势原因。P63
- 市场和成本的竞争压力
- 交付环境的日趋复杂和标准化
- 产品线工程的出现，其中，应系统地规划和执行多个相关软件产品的开发和演化，在产品线的所有成员中复用部分设计和实现。
16.统一软件工程过程模型（RUP）P64
- 迭代化开发，提前认知风险
- 需求管理，及早达成共识
- 基于构件，搭建弹性构架
- 可视化建模，打破沟通壁垒
- 持续验证质量，降低缺陷代价
- 管理变更，有序积累资产
17.RUP主要特点是一用例驱动的、以构件为中心的、风险驱动的迭代和增量的开发过程。
18.在RUP模型中，其横向按时间顺序来组织，将软件开发周期分成4个阶段，并以项目的状态作为开发周期的阶段名字——初始、细化、构造和移交，每个阶段目标明确。
19.每个阶段工作内容。P66
- 初始阶段：活动主要集中在需求工作中，有不少部分工作延续到分析与设计工作流。该阶段的工作几乎不涉及实现和测试工作流。
- 细化阶段：构造构架基线，确定生存周期构架里程碑。
- 构造阶段：行程系统的初步可运行能力，确定在用户环境中初步运行的软件产品，即最初操作性能里程碑。
- 移交阶段：完成产品发布，即产品发布里程碑。该阶段工作流的混合成都依赖于验收测试或β测试的反馈。
20.RUP的纵向按项目的实际工作内容——工作流来组织。工作流通常表示为一个内聚、有序的活动集合。8个顶层工作流：P66
- 管理工作流：控制过程并保证获得所有项目相关人员的取胜条件。
- 环境工作流：自动化过程并进化维护环境。
- 配置与变更工作流：自动化过程并进化维护环境。
- 业务与需求工作流：分析问题空间并进化需求制品。
- 设计工作流：解决方案建模并进化构建和设计制品。
- 实现工作流：构建编程并进化实现和实施制品。
- 测试与评估工作流：评估过程和产品质量的趋势。
- 部署工作流：将最终产品移交给客户。
21.RUP核心元素。RUP不仅仅是一个工程，它还是一个百科全书，软件工程学涉及的绝大部分概念都可以在这里找到准确的定义和说明。P67
22.计划的基础是工作量估算，而工作量的估算通常通过工作分解结构（Work Breakdown Structure, WBS）来获得。P72
23.传统的WBS（工作分解结构），将项目计划分解为离散的工作任务。P72
- 一个对于全部重要工作的描绘
- 一个用于分配职责的清晰的任务分解
- 一个用于进度安排、预算和开支跟踪的框架
24.传统的WBS的不足。P73
- 它们过早地围绕产品设计进行了结构化
- 它们过早地在过于详细或过于简单的细节上进行了分解、计划和预算
- 它们是针对具体目的，项目间横向的比较通常很难或者根本不可能
25.进化的WBS应该是围绕着框架组织计划的元素，而不是围绕产品框架组织这些元素。基本形式：P73
- 第1级WBS的元素是工作流（管理、环境、需求、设计、实现、评估和实施）
- 第2级是为生存周期的阶段而定义的（初始、细化、构造和移交）
- 第3级元素是为生产各阶段制品的活动而定义的。
26.剪裁的依据。P72
- 规模。更大型的项目需要更多层次和子结构。
- 组织结构。包含子承包商或跨多个组织实体的项目可能会引进对不同工作分解结构的分配限制。
- 定制开发程度。
- 业务环境。
- 经验。
27.RUP的质量管理贯穿其所有工作流程、阶段和迭代过程之中。P78
28.采用RUP模型的主要原因是多层次持续的规划与评估、判断架构中关键风险的经验、高效率的验证和评价手段、多工种之间的频繁沟通和多版本工作产品的管理。
29.MSF（Microsoft Solution Framework）基于里程碑的过程，加强了阶段评审，增强了项目的可预见性、参照螺旋模型组织过程，保持了迭代的灵活性，有利于创造。简化了螺旋次数，以发布为中心做一次回环（展开了即线性过程），传统的开发活动（分析、设计、编码、测试）大部分压缩到了一个子过程内，子过程内部活动可以迭代。
30.MSF特点：稳定化过程、里程碑驱动（主里程碑和临时里程碑）P79
31.本章小结。P80
- 软件开发初期遇到的主要问题是技术问题，因此编码修正模型、瀑布模型、增量模型主要规避的风险是技术风险。
- 为了规避需求风险出现了演化模型，对风险范围的不断扩充衍生了螺旋模型。
- 统一过程模型很好地总结了传统生存周期模型的优势与问题，集结了软件工程实践中的最佳经验，提出了自己的过程模型框架。
- MSF模型对产品级开发活动的组织提供了一种值得借鉴的思路。