第3章软件过程模型
合集下载
软件工程03-软件生命周期与开发模型
软件生命周期与开发模型
本章任务
本章任务-了解软件工程的发展史及常用的开发模型 知识目标： 了解软件工程的发展史 熟悉软件的生命周期 熟悉常用的开发模型 能力目标： 能描述软件的生命周期 能描述常用的软件开发模型及适用场景
1.软件工程概述
软件危机：落后的软件生产方式无法满足迅速增长的计算机 软件需求，从而导致软件开发与维护过程中出现一系列严重 问题的现象。 表现形式: 软件开发费用和进度失控。费用超支、进度拖延的情况屡 屡发生。有时为了赶进度或压成本不得不采取一些权宜之 计，这样又往往严重损害了软件产品的质量。 软件的可靠性差。尽管耗费了大量的人力物力，而系统的 正确性却越来越难以保证，出错率大大增加，由于软件错 误而造成的损失十分惊人。 生产出来的软件难以维护。很多程序缺乏相应的文档资料 ，程序中的错误难以定位，难以改正，有时改正了已有的 错误又引入新的错误。随着软件的社会拥有量越来越大， 维护占用了大量人力、物力和财力。
1.软件工程概述
传统软件工程
为迎接软件危机的挑战，人们进行了不懈的努力，这些努 力大致上是沿着两个方向同时进行的。 第一个方向是从软件开发管理的角度，希望实现软件 开发过程的工程化，它包括软件度量、项目估算、进 度控制、人员组织、配置管理、项目计划等。这方面 最为著名的成果就是提出了大家都很熟悉的“瀑布式 ”生命周期模型，它是在60年代末“软件危机”后出 现的第一个生命周期模型。如图5-1所示
（1）瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按 固定顺序而连接的若干阶段工作，形如瀑布流水 逐级下落，最终得到软件产品。 瀑布模型的核心思想是按工序将问题简化，将功 能的实现与设计分开，便于分工协作，即采用结 构化的分析与设计方法将逻辑实现与物理实现分 开。将软件生命周期划分为可行性研究与计划、 需求分析、设计、编码、测试和运行维护等六个 基本活动，并且规定了它们自上而下、相互衔接 的固定次序，如同瀑布流水，逐级下落。如果需 求发生变化，而需要逐级返回，修改所有相关的 文档及代码。
本章任务
本章任务-了解软件工程的发展史及常用的开发模型 知识目标： 了解软件工程的发展史 熟悉软件的生命周期 熟悉常用的开发模型 能力目标： 能描述软件的生命周期 能描述常用的软件开发模型及适用场景
1.软件工程概述
软件危机：落后的软件生产方式无法满足迅速增长的计算机 软件需求，从而导致软件开发与维护过程中出现一系列严重 问题的现象。 表现形式: 软件开发费用和进度失控。费用超支、进度拖延的情况屡 屡发生。有时为了赶进度或压成本不得不采取一些权宜之 计，这样又往往严重损害了软件产品的质量。 软件的可靠性差。尽管耗费了大量的人力物力，而系统的 正确性却越来越难以保证，出错率大大增加，由于软件错 误而造成的损失十分惊人。 生产出来的软件难以维护。很多程序缺乏相应的文档资料 ，程序中的错误难以定位，难以改正，有时改正了已有的 错误又引入新的错误。随着软件的社会拥有量越来越大， 维护占用了大量人力、物力和财力。
1.软件工程概述
传统软件工程
为迎接软件危机的挑战，人们进行了不懈的努力，这些努 力大致上是沿着两个方向同时进行的。 第一个方向是从软件开发管理的角度，希望实现软件 开发过程的工程化，它包括软件度量、项目估算、进 度控制、人员组织、配置管理、项目计划等。这方面 最为著名的成果就是提出了大家都很熟悉的“瀑布式 ”生命周期模型，它是在60年代末“软件危机”后出 现的第一个生命周期模型。如图5-1所示
（1）瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按 固定顺序而连接的若干阶段工作，形如瀑布流水 逐级下落，最终得到软件产品。 瀑布模型的核心思想是按工序将问题简化，将功 能的实现与设计分开，便于分工协作，即采用结 构化的分析与设计方法将逻辑实现与物理实现分 开。将软件生命周期划分为可行性研究与计划、 需求分析、设计、编码、测试和运行维护等六个 基本活动，并且规定了它们自上而下、相互衔接 的固定次序，如同瀑布流水，逐级下落。如果需 求发生变化，而需要逐级返回，修改所有相关的 文档及代码。
第3章软件项目全生命周期的阶段划分
软件项目启动过程完成的重要标志有： 成立项目管理委员会、任命项目经理、组织 项目团队、获取项目许可证、签订开发协议、 准备好一切软件开发的基础环境等。
第3章软件项目全生命周期的阶段划 分
第3章软件项目全生命周期的阶段划 分
其软件开发活动具有以下特点： 1)阶段性 要求在开发过程中前一阶段工作完成以 后，后一阶段工作才能开始。 2)阶段评审 对每一阶段完成的工作都要进行评审， 以利于尽早发现问题，避免后期的返工，如 果评审不合格，则不能开始下一阶段工作。 3)文档管理 每个阶段都明确规定了要完成的工作。 如果文档没有完成，就认为本阶段的工作没 有完成。
第3章软件项目全生命周期的阶段划 分
(4)模型的使用 在模型实际的使用不能生搬硬套现有的 开发模型，而是要深刻领会模型的精神，结 合自己软件项目的实际情况，选择符合本身 项目特点的开发模型。 瀑布模型无法解决软件需求不明确或不 准确的问题，会对整个软件开发工作带来严 重影响，最终可能导致开发出的软件并不是 用户真正需要的，且这一点只有在软件开发 完成后才可以被发现，所以瀑布模型对于需 求简单、明确的软件开发项目比较适合。
问题定义通常很简短，但在性质上它是 一个相对独立的步骤，不应该和其他步骤混 淆，更不应该省略。问题定义清楚后，形成 一份关于该项目的规模、目标及成本粗略估 计的报告书。
第3章软件项目全生命周期的阶段划 分
(2)可行性分析
可行性分析的主要目的是论证项目在时间、 资源、资金、效果、实现技术和方法等方面 的必要性和可能性。主要包括经济可行性、 技术可行性与操作可行性等方面。
第3章软件项目全生命周期的阶段划 分
利用演化模型进行软件开发的最大优点 或特点是在软件开发过程中，如果一次迭代 还不能满足用户的实际需求，可通过下一次 的迭代完成，这样就可以在一定程度上减少 软件开发的盲目性，提高软件的开发效率。
第3章软件项目全生命周期的阶段划 分
第3章软件项目全生命周期的阶段划 分
其软件开发活动具有以下特点： 1)阶段性 要求在开发过程中前一阶段工作完成以 后，后一阶段工作才能开始。 2)阶段评审 对每一阶段完成的工作都要进行评审， 以利于尽早发现问题，避免后期的返工，如 果评审不合格，则不能开始下一阶段工作。 3)文档管理 每个阶段都明确规定了要完成的工作。 如果文档没有完成，就认为本阶段的工作没 有完成。
第3章软件项目全生命周期的阶段划 分
(4)模型的使用 在模型实际的使用不能生搬硬套现有的 开发模型，而是要深刻领会模型的精神，结 合自己软件项目的实际情况，选择符合本身 项目特点的开发模型。 瀑布模型无法解决软件需求不明确或不 准确的问题，会对整个软件开发工作带来严 重影响，最终可能导致开发出的软件并不是 用户真正需要的，且这一点只有在软件开发 完成后才可以被发现，所以瀑布模型对于需 求简单、明确的软件开发项目比较适合。
问题定义通常很简短，但在性质上它是 一个相对独立的步骤，不应该和其他步骤混 淆，更不应该省略。问题定义清楚后，形成 一份关于该项目的规模、目标及成本粗略估 计的报告书。
第3章软件项目全生命周期的阶段划 分
(2)可行性分析
可行性分析的主要目的是论证项目在时间、 资源、资金、效果、实现技术和方法等方面 的必要性和可能性。主要包括经济可行性、 技术可行性与操作可行性等方面。
第3章软件项目全生命周期的阶段划 分
利用演化模型进行软件开发的最大优点 或特点是在软件开发过程中，如果一次迭代 还不能满足用户的实际需求，可通过下一次 的迭代完成，这样就可以在一定程度上减少 软件开发的盲目性，提高软件的开发效率。
软件工程第3章 软件需求分析(终)
第3章软件需求分析案例3: 图书馆图书信息管理系统“图书馆管理系统”是借助计算机来完成图书馆日常管理工作，能提供借书帐号注册、登录功能，基于图书标题、图书编号、作者、出版社的查询，也可以同时多个选项进行同时查询提供图书状态的查询，如可借和不可借，完成借书登记、还书的登记，能帮助管理人员完成图书信息的管理，如图书信息的修改、新图书的增加、旧图书的删除，图书分类工作，从而使图书馆的日常工作信息化、快捷化，减轻图书馆管理工作的困难。
因此，“图书馆管理系统”对于图书馆的日常管理工作和信息化到至关重要的作用。
【知识导入】通过对本章节内容的学习，掌握软件需求分析的基本内容，需求分析的特征及评审。
能够完成项目的需求分析，确立正确的项目开发思路。
软件需求是一个项目的开端，是整个软件项目开发的基础。
即表示该软件经过可行性分析后确立有此需求，而开发该项目。
因此，需求分析在整个项目建设过程中至关重要，是项目开发的基石，基石的牢固程度决定了后期项目的进展以及项目开发完工后的产品质量的优劣，可以说需求分析的好坏直接影响到软件项目开发的成败。
软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。
IEEE （美国电气和电子工程师协会）是这样对需求分析做定义的：①用户解决问题或达到系统目标所需要的条件②为满足一个协议、标准、规格或其他正式制定的文档，系统或系统构建所需满足和具有的条件或能力③将需求要求条件进行文档化描述。
这个概念全方位阐述了需求的概念，较完整的表达了软件需求的内涵和外延，便于用户的全面理解。
而需求分析最终就是通过对应用问题及其环境的分析与理解采用一系列的分析方法和技术将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。
系统分析阶段产生的系统规格说明书和项目规划是软件需求分析的基础，分析人员需要从软件的角度对其进行检查和调整，并在此基础上展开需求分析。
需求分析阶段的成果主要是需求规格说明书，该成果又是软件设计、编码、测试直至维护的主要基础。
软件工程-软件过程模型
4 演化模型-螺旋模型
Evolutionary Model
螺旋模型的基本思想
每一个螺旋周期（Spiral model sectors）包 含四个部分： （1）确定目标，选择方案，设定约束条件， 选定完成本周期所定目标的策略。 （2）分析该策略可能存在的风险。 （3）在排除风险后，实现本螺旋周期的目标。 （4）评价前一步的结果，并且计划下一轮的 工作。
第二章 软件过程模型
软件生存周期 软件开发模型 瀑布模型 进化式模型 演化模型 形式化开发
第一节 软件生存周期
软件生存周期的概念： 一个软件从计划起，到废弃不用止。
软件生存周期包括：计划、开发、运行。
第二节 软件开发模型概念
软件开发模型的概念：
为整个软件生存期建立的模型。
交付客户
构件n
规格说明
设计
实现和集成
交付客户
增量模型的基本思想
每个增量提供系统功能的一个子集，一个增 量完成并交付，部分系统功能可以提前交付 使用。 对增量中服务的分配取决于服务优先次序。 最高优先权的服务首先被交付。 第一个增量往往是核心的产品。 开发者能通过对系统的经验帮助理解后面的 增量需求和目前增量后续版本的需求变更。
思考题
为以下各系统提出合适的软件过程模型，阐 述理由： （1） 汽车防锁死刹车控制系统 （2）一个支持软件维护的虚拟现实系统 （3）大学记账系统，准备替换一个已存在的 系统 （4）一个位于火车站的交互式火车车次查询 系统
建立原型系统的方法
原型系统仅包括未来系统的主要功能，以及 系统重要的接口。 开发原型系统尽可能使用能缩短开发周期的 语言和工具。
3 演化模型-增量模型
Evolutionary Model
软件过程的定义与模型
过程定义了运用方法的顺序，应该交付的文档资料，为保证软件质量和 协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里 程碑。通常，使用生命周期模型简洁地描述软件过程。生命周期模型规定了 把生命周期划分为哪些阶段及各个阶段的执行顺序，因此也称为过程模型。
5
第二节
软件生命周期
• 软件生命周期的概念 • 传统软件生命周期的各个阶段
统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。
29
敏捷过程与极限编程
随着计算机技术的迅猛发展和全球化进程的加快，软件需求常 常发生变化，强烈的市场竞争要求更快速的开发软件，同时软件 也能够以更快的速度更新。传统的方法在开发时效上时常面临挑 战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。 敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程 方法，它更强调软件开发过程中各种变化的必然性，通过团队成 员之间充分的交流与沟通以及合理的机制来有效地响应变化。
11
几种模型之间的关系
5．软件测试 软件测试是保证软件质量的关键步骤。软件测试的目的是发现软件产品中存在的 软件缺陷，进而保证软件产品的质量。在软件开发的实践中，软件缺陷的产生是必然 的。软件缺陷发现得越晚，弥补缺陷所需的成本就越高，损失也就越大。为了尽早发 现软件缺陷，有效地进行软件测试是必须的。按照测试点的不同，测试可以分为单元 测试、集成测试、系统测试和验收测试。
17
快速原型模型
快速原型的基本思想是快速建 立一个能反映用户主要需求的原型系 统，让用户在计算机上试用它，通过 实践来了解目标系统的概貌。通常， 用户试用原型系统之后会提出许多修 改意见，开发人员按照用户的意见快 速地修改原型系统，然后再次请用户 试用……反反复复地改进，直到原型 系统满足用户的要求。
5
第二节
软件生命周期
• 软件生命周期的概念 • 传统软件生命周期的各个阶段
统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。
29
敏捷过程与极限编程
随着计算机技术的迅猛发展和全球化进程的加快，软件需求常 常发生变化，强烈的市场竞争要求更快速的开发软件，同时软件 也能够以更快的速度更新。传统的方法在开发时效上时常面临挑 战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。 敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程 方法，它更强调软件开发过程中各种变化的必然性，通过团队成 员之间充分的交流与沟通以及合理的机制来有效地响应变化。
11
几种模型之间的关系
5．软件测试 软件测试是保证软件质量的关键步骤。软件测试的目的是发现软件产品中存在的 软件缺陷，进而保证软件产品的质量。在软件开发的实践中，软件缺陷的产生是必然 的。软件缺陷发现得越晚，弥补缺陷所需的成本就越高，损失也就越大。为了尽早发 现软件缺陷，有效地进行软件测试是必须的。按照测试点的不同，测试可以分为单元 测试、集成测试、系统测试和验收测试。
17
快速原型模型
快速原型的基本思想是快速建 立一个能反映用户主要需求的原型系 统，让用户在计算机上试用它，通过 实践来了解目标系统的概貌。通常， 用户试用原型系统之后会提出许多修 改意见，开发人员按照用户的意见快 速地修改原型系统，然后再次请用户 试用……反反复复地改进，直到原型 系统满足用户的要求。
【软件体系结构】 复习
第一章1. 体系结构发现、演化、重用体系结构发现解决如何从已经存在的系统中提取软件的体系结构，属于逆向工程范畴。
由于系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动，称之为软件体系结构演化。
体系结构重用属于设计重用，比代码重用更抽象。
由于软件体系结构是系统的高层抽象，反映了系统的主要组成元素及其交互关系，因而较算法更稳定，更适合于重用。
2.基于软件体系结构的软件开发方法：问题定义—>软件需求—>软件体系结构—>软件设计—>软件实现3.评价软件体系结构的方法权衡分析方法（ATAM方法），软件体系结构分析方法（SAAM方法）,中间设计的积极评审（ARID方法）第二章1. 建模结构模型：研究结构模型的核心是体系结构描述语言。
以体系结构的构件，连接件和其他概念来刻画结构。
并力图通过结构来反映系统的重要语义内容。
框架模型：与结构模型类似，但不太侧重细节，而侧重于整体结构。
动态模型：是对结构和框架模型的补充，研究系统大颗粒的行为性质。
过程模型：研究构造系统的步骤和过程，结构是遵循某些过程脚本的结果。
功能模型：认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。
功能模型可以看作是一种特殊的框架模型。
4+1视图模型：逻辑视图、进程视图、物理视图、开发视图和场景视图逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图开发视图通过系统输入输出关系的模型图和子系统图来描述。
进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
物理视图主要考虑如何把软件映射到硬件上。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
第3章软件需求分析与建模
应如何实施。
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
软件工程导论第3章
2.访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍 然广泛使用的需求分析技术。 访谈有两种基本形式： 正式访谈：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题， 以鼓励被访问人员说出自己的想法。 调查表是当需要调查大量人员的意见时的一个十分有效的做法。 分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户， 以便向他们询问在分析调查表时发现的新问题。 在访问用户的过程中可以使用情景分析技术。情景分析技术的 用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用户理解， 而且还可能进一步揭示出一些分析员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术能保证用户在 需求分析过程中始终扮演一个积极主动的角色。
（1） 数据对象
数据对象是对软件必须理解的复合信息的抽象。所谓 复合信息是指具有一系列不同性质或属性的事物，仅有单 个值的事物(例如，宽度)不是数据对象。 数据对象可以是外部实体(例如，产生或使用信息的任 何事物)、事物(例如，报表)、行为(例如，打电话)、事件 (例如，响警报)、角色(例如，教师、学生)、单位(例如，会 计科)、地点(例如，仓库)或结构(例如，文件)等。总之，可 以由一组属性来定义的实体都可以被认为是数据对象。 数据对象彼此间是有关联的，例如，教师“教”课程， 学生“学”课程，教或学的关系表示教师和课程或学生和 课程之间的一种特定的连接。
（4）需求验证 由软件开发者和用户一起来进行软件需求规格
说明的复审。确保需求规格说明可作为软件设计和最 终系统验收的依据。
二. 需求获取的常用方法
1. 建立联合分析小组 建立一个由用户、系统分析员和领域专家参加 的联合分析小组，密切合作，共同标识问题，提出 解决方案要素，商讨不同方案并指定基本需求。 这是一种面向团队的需求收集法，又称为简易 的应用规格说明技术。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.5 构件集成模型
构件集成模型是基于构件的开发模型 构件集成模型： 整个系统模块化 复用构件库中的软件构件 构件集成模型是演化形的，开发过程是迭代的 5个阶段： 软件的需求分析和定义 体系结构设计 构件库建立 应用软件构建 测试和发布
构件集成模型
需求分析和定义 体系结构设计 构件库建立 应用软件构建 测试和发布 1：N
构件集成模型存在问题
模型由于采用自定义的组装结构标准，缺乏通用的组
装结构标准，这样就引入了比较大的风险。
可复用性和软件高效性不容易协调，需要比较有经验
的开发人员。
3.6 统一过程模型
统一过程（Unified Process，UP) 是风险驱动的、基
于用例技术的、以架构为中心的、迭代的、可配置的 软件开发流程。 统一过程是以用例驱动的，以架构为中心，迭代和增 量的过程。 统一过程是一个软件开发过程，是一个通用的过程框 架：
初始
细化 构造
移交
统一过程的四个阶段
统一过程五个核心工作流
需求(Requirements Capture)：致力于开发正确的系统
分析(Analysis)：更精确地理解需求 设计(Design)：深入理解与非功能性需求和约束相联
系的问题 实现(Implementation)：实现系统与集成 测试(Test)：验证实现的结构
敏捷开发12条原则
我们最优先要做的是通过尽早的、持续的交付有价值
的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利
用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几
个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天
每隔一定时间，团队会在如何才能更有效地工作方面
进行反省，然后相应地对自己的行为进行调整。
3.7.1 极限编程
极限编程（eXtreme Programming，XP）是一种软件
工程方法学，是敏捷开发中最富有成效的方法学之一 由KentBeck在1996年提出 具有强沟通、简化设计、迅速反馈等特点
每个时期又细分为若干个阶段。把整个软件生存周期 划分为若干阶段，使得每个阶段有明确的任务，使规 模大，结构复杂和管理复杂的软件开发变的容易控制 和管理。
软件生存周期包括可行性分析、项目计划、需求分析
、软件设计、编码与测试、维护等阶段，每个阶段有 包含一系列的活动。
3.2 瀑布模型
瀑布模型将软件生命周期划分为软件计划、需求分析
极大地增加了工作量。 用户只有在末期才能见到开发成果。 经常遇到等待其他成员完成其所依赖的任务情况。
3.3 增量模型
增量模型（Incremental Model）也称为渐增模型，是
在项目的开发过程中以一系列的增量方式开发系统。 软件被作为一系列的增量构件来设计、实现、集成和 测试，每一个构件是由多种相互作用的模块所形成的 提供特定功能的代码片段构成. 增量方式包括：
和定义、设计、实现、测试、运行和维护这6个阶段 ，规定了它们自上而下、相互衔接的固定次序，如同 瀑布流水逐级下落。
从本质来讲，它是一个软件开发架构，开发过程是通
过一系列阶段顺序展开的，从系统需求分析开始直到 产品发布和维护，每个阶段都会产生循环反馈.
瀑布模型示意图
瀑布模型
它是一个软件开发架构，开发过程是通过一系列阶段
核心工作流
统一过程准则
准则 迭代的开发软件 需求管理 基于构件的体系结构 可视化软件建模 验证软件质量 控制软件的变更 统一过程主要的优点是提高了团队生产力
3.7 敏捷过程
敏捷不是一个过程，是一类过程的统称。
敏捷方法的两大主要特征： 对“适应性”的强调 对“人”的关注 做法： 快速响应:引入迭代式的开发手段 将整个软件生命周期分解为若干个小的迭代周期 获取切实有效的客户反馈 提出12条基本原则
结对编程
优势： 可以减少风险 可以使团队生产效率更高 是知识传播的最好途径 可以打造出最佳的合作团队。 可以生成更好的代码 方法： 面对面结对编程 分布式结对编程
软件开发模型是指软件开发全部过程、活动和任务的结构框架，
小结
能清晰、直观地表达软件开发全过程，明确规定了要完成的主要 活动和任务，用来作为软件项目工作的基础。 瀑布模型是一种线性模型，文档驱动的模型。 增量提交模型采用一系列的增量方式开发系统。 螺旋模型结合瀑布模型和快速原型，是一种风险驱动的开发模型
风险识别
风险分析 风险控制
特别适合于大型复杂的系统
每一个周期都包括需求定义、风险分析、工程实现和
评审
螺旋模型示意图
螺旋模型活动
四个象限分别代表了以下活动： 制定计划：确定软件目标，选定实施方案，确定项目开 发的限制条件； 风险分析：分析评估所选方案，考虑如何识别和消除风 险； 实施工程：实施软件开发和验证； 客户评估：评价开发工作，提出修正建议，制定下一步 计划。 螺旋模型是风险驱动的模型
结对编程(Pair-Programming) 是XP中非常重要的实践
之一。
定义：两个人坐在同一台计算机前面，使用相同的键
盘和鼠标来开发同样的一个模块，一个称为驾驶者 (Driver)，负责代码的键入，另外一个称为领航员 (Navigator)，负责监看与决策，包括低级错误和方向 性的错误。当出现的一个问题对其中一个人来说，难 以解决，而恰好是另外一个人的强项的时候，那么角 色就会发生转换。
而是交付满足客户需求的可运行产品的一个子集。 存在缺陷：
加入构件必须不破坏已构造好的系统部分；
很容易退化为边做边改模型，从而使软件过程的控制失
去整体性。
3.4 螺旋模型
螺旋模型（Spiral Model）是结合了瀑布模型和快速原
型模型的迭代开发模型 强调了其他模型均忽略了的风险分析：
适合于规模小、进度紧、需求不稳定、开发小项目的
小团队。
极限编程
特点： XP模型是“轻量型”或“灵活”的软件过程模型 与面向对象语言结合的开发方案 “专家协作”的开发方式，解决难点问题 重视客户反馈 核心有四个要点： 交流 简单 反馈 勇气
3.7.2 结对编程
增量开发：以一定的时间间隔开发部分工作软件
增量提交：以一定的时间间隔增量方式向用户提交工作
软件及相应文档
增量模型融合了线性顺序模型的基本成份和原型实现
ቤተ መጻሕፍቲ ባይዱ
模型的迭代特征。
增量构造模型
需求分析 编码2 设计 编码3 编码1 测试1 测试3 测试2
增量模型
增量模型在各个阶段并不交付一个可运行的完整产品，
都在一起工作。
围绕被激励起来的个体来构建项目，给他们提供所需
的环境和支持，并且信任他们能够完成工作。
敏捷开发12条原则(续)
在团队内部，最具有效果并富有效率的传递信息的方
法，就是面对面的交谈。 工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和
用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单是最根本的。 最好的构架、需求和设计出于自组织团队。
第3章 软件过程模型（内容提要）
瀑布模型
增量模型 螺旋模型
协同开发模型
面向对象模型 面向方面的软件开发
3.1 软件生存周期
软件也有一个从生到死的过程，这个过程一般称之为
软件的软件生存周期或生命周期（Software Development Life Cycle）
软件生存周期可划分为定义、开发和运行三个时期，
构件集成模型利用模块化方法将整个系统模块化，复用构件库中 统一过程模型是以用例驱动的，以架构为中心，迭代和增量的过
的软件构件，通过组合手段提高应用软件系统过程的效率和质量。 程。
敏捷方法是一组敏捷实践技术的总称，包括极限编程、自适应软
件开发、动态系统开发和特征驱动开发等等
顺序展开的。 每个阶段都会产生循环反馈
各个阶段产生的文档是维护软件产品时必不可少的，
没有文档的软件几乎是不可能维护的。 瀑布模型是一种文档驱动的过程模型
瀑布模型特点
顺序性和依赖性
推迟实现 质量保证的观点
是一种线性模型
强调文档的作用
瀑布模型存在问题
各个阶段的划分完全固定，阶段之间产生大量的文档，