02、软件生命周期模型
02第2章软件生命周期及开发模型
2、原型模型
Ø 增量模型在开发软件过程中，是将软件产品作为一系列的增量 构 件来设计、编码、集成和测试；
Ø 每个构件由多个互相作用的模块构成，且能够完成特定的功能； Ø 采用增量模型开发，首先建立的增量构件是实现软件系统最基
第2章软件生命周期及开发模型软件过程概述21传统的软件过程模型22面向对象的软件过程模型23第2章软件生命周期及开发模型敏捷软件开发过程模型2421软件过程概述1软件生命周期软件也有一个孕育诞生成长成熟衰亡的生存过程
第2章 软件生命周期及开发模型
【学习目标】掌握软件的生命周期的概念，明确学习软件 过程模型的意义，掌握各种过程模型的特点与适用范围， 掌握面向对象软件过程模型的内容与过程，了解敏捷开发 软件过程模型的内容与过程。 【教学方法】案例教学法
2.4 敏捷软件开发过程模型
2.1 软件过程概述
1
软件生命周期
主
要
内
容
2 软件生命周期各阶段的任务
1、软件生命周期
软件也有一个孕育、诞生、成长、成熟、衰亡的生存过 程。称其为计算机软件的生命周期。
软件生命周期可划分为若干个阶段。问题定义、可行性研 究、需求分析、概要设计、详细设计、编码和单元测试、综 合测试、系统运行和维护。
2、原型模型
快速原型模型（Rapid Prototype Model）
Ø快速原型模型的第一步是建造一个快速原型，实现客户 或未来的用户与系统的交互，用户或客户对原型进行评价， 进一步细化待开发软件的需求。通过逐步调整原型使其满 足客户的要求，开发人员可以确定客户的真正需求是什么； 第二步则在第一步的基础上开发客户满意的软件产品;
软件工程第2讲 软件生命周期模型
敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较5敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较57P32: 2.9.2P23: 2.2 P25: 2.3P34: 2.9.3模型构造多使用脚本语言、基于现有基础代码库、UI工具制作，制作过程一般不会考虑性能、稳定敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较5迭代-递增生命周期模型递增也是软件工程的一个固有特性P27P26: 2.5P28P29P30 2.7敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较58个体和交互胜过过程和工具以人为本我相信没有比面对面交流更高效的沟通渠道了•尊重和信任激发个人内心的责任感和使命感，激发了个体的潜能。
•基于互相信任的前提，敏捷提倡自治的全功能团队。
在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。
•要摒弃这种重流程和重工具，提倡轻量级流程和轻量级工具，而这些流程和工具又在促进个体交互。
比如，我们在日常工作中会使用Trello、Jira、Keynote等工具。
可以工作的软件胜过面面俱到的文档价值导向为客户交付可工作的软件是我们的核心目标•我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上。
•但这不代表我们要抵制任何文档。
实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
•在开发过程中，交互设计原型也是一种轻量级文档，交互设计师交付可以尽早地跟团队和客户进行确认验收的核心业务场景的原型，快速收集反馈。
客户合作胜过合同谈判客户团队帮助客户实现他们真正想要的价值•让客户也作为团队的一分子，跟客户建立信任的合作关系取代敌对的谈判关系。
•需求的变化往往来自客户，让客户参与进来可以在开发的过程中尽早的发现变化，从而尽早采取解决方案。
第2章软件生命周期模型PPT课件
➢ 这种按时间分程的思想方法是软件工程中的一 种思想原则，即按部就班、逐步推进，每个阶 段都要有定义、工作、审查、形成文档以供交 流或备查，以提高软件的质量。
2020/11/23
2
软件生命周期各阶段的主要任务:
（1） 可行性分析和项目开发计划 ➢ “要解决的问题是什么”
➢ 该问题有行得通的解决办法吗？
➢ 若有解决问题的办法，则需要多少费用？需要 多少资源？需要多少时间？
（2） 需求分析
需求分析阶段的任务不是具体地解决问题，而 是准确地确定“软件系统必须做什么？”确定 软件系统必须具备哪些功能。
2020/11/23
3
（3） 概要设计
在概要设计阶段，开发人员要把确定的各项功 能需求转换成需要的体系结构，概要设计就是 设计软件的结构，该结构由哪些模块组成，这 些模块的层次结构是怎样的，这些模块的调用 关系是怎样的，每个模块的功能是什么。
2020/11/23
11
（4）缺点：
➢ 缺乏灵活性，不能适应用户需求的改变。
➢ 开始阶段的小错误被逐级放大，可能导致软 件产品报废。
➢ 返回上一级的开发需要十分高昂的代价。
➢ 随着软件规模和复杂性的增加，软件产品成 功的机率大幅下降。
2020/11/23
12
2.3 原型模型
原型模型(Prototype Model)在初步需求分析之 后，马上向客户展示一个软件产品原型，对客 户进行培训，让客户试用，在试用中收集客户 意见，根据客户意见立刻修改原型，之后再让 客户试用，反复循环几次，直到客户确认为止。
2020/11/23
13
停止
软件工程软件生命周期模型
软件工程软件生命周期模型在软件工程领域，软件生命周期模型是一种重要的框架，用于指导软件开发的过程。
它为软件开发团队提供了一种结构化的方法，以确保软件的开发能够高效、高质量地完成。
软件生命周期模型就像是一张地图，指引着开发人员从项目的启动到最终的交付。
它涵盖了软件从概念形成到退役的整个过程，包括一系列的阶段、活动和任务。
常见的软件生命周期模型有瀑布模型、快速原型模型、增量模型、螺旋模型和敏捷模型等。
瀑布模型是最早出现的软件生命周期模型之一。
它将软件开发过程分为明确的几个阶段，如需求分析、设计、编码、测试和维护。
每个阶段都必须在前一个阶段完成且经过评审后才能开始。
这种模型的优点是流程清晰，文档规范。
但它的缺点也很明显，如果在后期发现前期的错误，修改成本会很高，而且不适应需求的频繁变更。
快速原型模型则是在获取基本需求后，快速构建一个原型系统。
用户通过使用原型来进一步明确需求，开发人员根据反馈进行修改和完善。
这个模型的好处是能够快速获得用户的反馈，尽早发现问题。
但由于原型往往不够完善，可能会给用户造成误解。
增量模型是把软件系统逐步分解为多个增量构件，每个构件分别开发和交付。
这样可以在较短的时间内交付部分功能，让用户逐步看到成果。
但它对软件的架构设计要求较高，需要很好地规划各个增量之间的接口。
螺旋模型则是将瀑布模型和快速原型模型结合起来，并加入了风险分析。
它沿着螺旋线不断迭代，每一轮迭代都包括制定计划、风险分析、实施工程和客户评估等步骤。
这种模型适用于大型、复杂且高风险的项目，但管理成本相对较高。
近年来，敏捷模型在软件开发中越来越受欢迎。
敏捷开发强调团队的快速响应和持续交付，通过短周期的迭代来不断完善软件。
常见的敏捷方法有 Scrum 和 Kanban 等。
敏捷模型注重人与人之间的沟通和协作，能够更好地适应需求的变化，但对团队成员的素质和自组织能力要求较高。
在选择软件生命周期模型时，需要考虑多个因素。
首先是项目的特点，比如项目的规模、复杂度、需求的稳定性等。
软件生命周期
软件生命周期软件生命周期(SDLC，软件生存周期)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。
但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
一、软件生命周期(SDLC)的六个阶段1、问题的定义及规划此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。
需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
"唯一不变的是变化本身。
"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
软件设计一般分为总体设计和详细设计。
好的软件设计将为软件程序编写打下良好的基础。
4、程序编码此阶段是将软件设计的结果转换成计算机可运行的程序代码。
在程序编码中必须要制定统一，符合标准的编写规范。
以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。
测试的方法主要有白盒测试和黑盒测试两种。
在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护软件维护是软件生命周期中持续时间最长的阶段。
在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。
02-1 软件生命周期与开发模型
6
二、瀑布模型
7
• 1970年W.Royce提出瀑布模型 • 1.模型的本意：阶段间具有顺序性和依赖性
2.模型的特点：
文档驱动 过程不可逆转
（1）在开发时间内需求没有或很少变化。 （2）分析设计人员对应用领域很熟悉。 （3）低风险项目（对目标、环境很熟悉）。 （4）用户使用环境很稳定。 （5）用户除提出需求以外，很少参与开发工作。
•原型可作为单独的过程模型，也常被作为一 种方法或实现技术应用于其它过程模型中。
25
五、 迭代模型 （Iterative Model）
• 代表：RUP（Rational Unified Process）模型
26
• 这里所讲的迭代模型是RUP推出的一种 “逐步求精”的面向对象的软件开发过程 模型，被认为软件界迄今为止最完善的、 商品化的开发过程模型。
快速计划 交流 快速设计方式 建模
部署交付和 反馈
构建原型
17
原型模型
• 软件企业界的主流开发模型. • 1．模型的本意 • 原型模型（Prototype Model）的本意是： 在初步需求分析之后，马上向客户展示一个 软件产品原型(样品)，对客户进行培训，让 客户试用，在试用中收集客户意见，根据客 户意见立刻修改原型，之后再让客户试用， 反复循环几次，直到客户确认为止。
14
• 4．模型的优点 • （1）由于将一个大系统分解为多个小系统， 这就等于将一个大风险分解为多个小风险， 从而降低了开发难度。 • （2）人员分配灵活，刚开始不用投入大量 人力资源。如果核心模块产品很受欢迎， 则可增加人力实现下一个增量。当配备的 人员不能在设定的期限内完成产品时，它 提供了一种先推出核心产品的途径。即可 先发布部分模块给客户，对客户起到镇静 剂的作用。
2_软件生存周期及模型
软件产品
基线 检查点 里程碑 评审 审计 顾客>客 户>用户 现有系统 目标系统
14
软件生存周期
软件生存周期模型
15
2.2 软件生存周期模型概念
模型是为了理解事物而对事物作出的一种抽 象，它忽略了不必要的细节，是事物的一种 抽象描述形式 。
软件生存周期模型是描述软件开发过程中各种
活动如何执行的模型。它确立了软件开发和演 化中各阶段的次序以及各阶段活动的准则，确 立开发过程所必须遵守的规定和限制等。
11 编码
12 测试
第2块 第2块 第2块 第2块 第3块 第3块 第3块 第4块 第4块 …第N块
19
增量模型特点
遵循递增方式进行软件开发。开发一部 分，向用户展示一部分。 增量模型是一种非整体开发的模型。 适用于：
1）使用面向对象语言或第四代语言（VB、 Delphi、Qt等）； 2）需求可能发生变化，客户接受分阶段交付； 3）分析设计人员对应用领域不熟悉，难以一步 到位； 4）项目风险高；
基本任务：通过各种类型的测试活动使软件达到 预定的要求。 结束标准：软件合格，能交付用户使用。
测试
7
软件维护时期
基本任务：通过各种必要的维护活动使系 统持久地满足用户需要。
8
交互设计
美国的Alan Cooper提出，交互设计应该作 为软件生存周期的一个重要阶段考虑进去（具 体可参看《软件开发的创新思维》，刘瑞挺等 译，电子工业出版社出版）。 可行性研究和项目开发计划、需求分析、 交互设计、 概要设计、详细设计、编码、测试、维护 解决软件的可用性，最佳满足用户的使用目标。 结束标准：达成共识的交互设计文档
在CMM中软件产品是最终用户使用的软件。它是软件工作产品的一部分。 它是软件工作产品。它是要经内部和外部评审过的，并且是下一阶段工 作的基础，一根基线是一个里程碑或一个检查点。 它是由时间、计划、事件驱动的检查工作进度和质量的一个记号，一个 检查点不一定是基线或里程碑。 它是一个记号，只需经过内部评审。它是一个检查点，但不一定是基线。 是对软件工作产品质量的一次开会或汇签活动。 是复查评审活动程序的合法性，是否按程序与规范进行。 客户是顾客的一部分，顾客包括潜在的客户。用户是软件产品的最终使 用者，用户是客户的一部分。 现有系统是用户当前正在使用的系统（可能是手工系统）；目标系统是 将要实现的系统。
12--软件生命周期模型
原型模型特点
• 快速原型用于获取用户需求；进化原型用于产品完
善；
• 快速原型是暂时使用，进化原型是应用于整个生命
周期；
• 原型进化模型能够较好适应开发中途的需求变更 • 原型模型阶段不明确，管理较困难 • 原型的不断完善可能导致维护问题
3 增量模型
第一轮 第二轮 第三轮 分析组 分析 分析 分析 设计 设计 设计 设计组 编码 编码 编码 编码组 测试 测试 测试 使用 使用 使用 测试组
• •
小结
• 什么是软件生命周期？ • 什么是软件生命周期模型？ • 典型的软件生命周期模型有哪些？ • 思考：什么驱动了软件生命周期模型的演进 • 各模型的主要特点和优缺点？
软件生命周期模型
• 软件生命周期是软件从项目需求定义直至 软件生命周期是软件从项目需求定义直至 软件从项目需求定义
软件经使用后废弃为止， 软件经使用后废弃为止，所经历的系统开 废弃为止 运作和维护等的全部过程 发、运作和维护等的全部过程
• 软件生命周期模型：某种软件生命周期及
其活动的框架性描述
• 常用的生命周期模型有瀑布模型、原型模
• RUP又是一套软件工程方法的框架，各个组织 RUP又是一套软件工程方法的框架，各个组织
可根据自身的实际情况，以及项目规模对RUP 可根据自身的实际情况，以及项目规模对RUP 进行裁剪和修改，以制定出合乎需要的软件工 程过程。 与统一建模语言（Unified Model Language , 统一建模语言（ 以下简称UML）的良好集成、多种CASE工具的 以下简称UML）的良好集成、多种CASE工具的 支持、不断的升级与维护，迅速得到业界广泛 的认同，越来越多的组织以它作为软件开发模 型框架
增量模型特点
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
这个阶段的基本任务是，概括地回答“怎样实现目标 系统”这个问题。概要设计又称为初步设计、逻辑设计、 高层设计或总体设计。
首先，应该设计出实现目标系统的几种可能的方案。 概要设计的另一项主要任务就是设计程序的体系结构， 也就是确定程序由哪些模块组成以及模块间的关系。
5.详细设计
概要设计阶段以比较抽象概括的方式提出了解决问题的办 法。详细设计阶段的任务就是把解法具体化，也就是回答 “应该怎样具体地实现这个系统”这个关键问题。这个阶段 的任务还不是编写程序，而是设计出程序的详细规格说明。
4.能力成熟度模型
• Capability Maturity Model， CMM是改进软 件过程的一种策略，与实际使用的过程模型 无关。
• 能力成熟度模型的结构
能力成熟度等级
• 初始级 • 可重复级 • 已定义级 • 已管理级 • 优化级
5.Rational统一过程（RUP）
• 软件工程过程
各个阶段应该完成的基本任务： 1.问题定义 问题定义阶段必须回答的关键问题是：“要解决的 问题是什么”。
2.可行性研究 这个阶段要回答的关键问题是：“上一个阶段所确定 的问题是否有行得通的解决办法”。
3.需求分析
这个阶段的任务仍然不是具体地解决客户的问题，而是 准确地回答“目标系统必须做什么”这个问题。这个阶段的 另外一项重要任务，是用正式文档准确地记录对目标系统的 需求，这份文档通常称为规格说明(specification)。
运行维护时期的主要任务是使得软件持久地满足用户需 要并长期为用户服务。具体地说，当软件在使用过程中发 现错误时应该加以改正；当环境改变时应该修改软件以适 应新的环境；当用户有新的要求时应该及时修改或扩充软 件以满足用户的新需求。通常对维护时期不再进一步划分 阶段，但是每一次维护活动实质上都是一次压缩和简化了 的定义和开发过程。
因此，原型系统的内部结构并不重要，重要的是， 必须迅速地构建出原型然后根据用户的意见迅速地修改 原型，为此应该使用快速原型语言或工具来构建原型。
3.3 增量模型
增量模型也称为渐增模型，如图1.5所示。
图1.5 增量模型
增量模型
分析
设计
编码
测试
分析
设计
编码
测试
分析
设计
编码
测试
分析
设计
编码
测试
使用增量模型开发软件时，把软件产品作为一系列 的增量构件来设计、编码、集成和测试。每个构件由多 个相互作用的模块构成，并且能够完成特定的功能。使 用增量模型时，第一个增量构件往往实现软件的基本需 求，提供最核心的功能。
但传统的瀑布模型过于理想 化，事实上，人在工作过程中 不可能不犯错误，潜伏的错误 将在后续阶段被陆续发现。在 设计阶段可能发现规格说明文 档中的错误，而设计上的缺陷 或错误可能在实现过程中显现 出来，在综合测试阶段将发现 需求分析、设计或编码阶段的 许多错误。当然，发现错误就 必须及时改正，因此，实际的 瀑布模型是带“反馈环”的， 如图所示（图中实线箭头表示 开发过程，虚线箭头表示维护 过程）。
3.5 喷泉模型
迭代是软件开发过 程中普遍存在的一种内 在属性。经验表明，软 件过程各个阶段之间的 迭代或一个阶段内各个 工作步骤之间的迭代， 在面向对象范型中比在 结构化范型中更常见。 图示的喷泉模型是典型 的面向对象生命周期模 型。
“喷泉”这个词体现了面向对象软件开发过程迭代 性和无缝性。
为避免使用喷泉模型开发软件时开发过程过分无序， 应该把一个线性过程(例如，快速原型模型或图中的中 心垂线)作为总目标。但是，同时也应该记住，面向对 象范型本身要求经常对开发活动进行迭代或求精。
软件生命周期模型规定了把软件生命周期划分成哪些阶段 及各个阶段的执行顺序，也称为软件过程模型，它是描述软 件过程的一种常见的方式。
2 软件生命周期
概括地说，软件生命周期由软件定义、开发和运行维 护三个时期组成。每个时期又可以进一步划分成若干个阶 段。
软件定义时期的任务是定义所要开发的软件，具体地 说，就是确定软件开发工程必须完成的总目标；确定工程 的可行性；导出实现工程目标应该采用的策略及软件必须 具有的功能；估算完成该项开发工程需要的资源和成本， 并且制定工程进度表。这个时期的工作通常又称为系统分 析，由系统分析员采用结构化分析方法或面向对象分析方 法完成。通常把软件定义时期进一步划分成问题定义、可 行性研究和需求分析三个阶段。
完整的螺旋模型如图所示：
图中带箭头的点划线的长度代表当前累计的开发费用 ，螺线旋过的角度值代表开发进度。螺旋线每个周期对应 于一个开发阶段。每个阶段开始时（左上象限）的任务是 ，确定该阶段的目标、为完成这些目标选择方案及设定这 些方案的约束条件。接下来的任务是，从风险角度分析上 一步的工作结果。努力排除各种潜在的风险，通常用建造 原型的方法来排除风险。如果风险不能排除，则停止开发 工作或大幅度地削减项目规模。如果成功地排除了所有风 险，则启动下一个开发步骤（右下象限），在这个步骤的 工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工 作成果并计划下一个阶段的工作。
快速原型模型
通常，用户试用原型系统之后会提出许多修改意见， 开发人员按照用户意见快速地修改原型系统，然后再次 请用户试用，……。经过多次反复之后，一旦用户认为 现在这个原型系统确实能做他们所需要的工作，开发人 员便可以依照这个原型系统书写规格说明文档，根据这 份文档开发出的软件应该能够满足用户的真实需要。
6.编码和单元测试
这个阶段的关键任务是写出正确的容易理解、容易维护 的程序模块。
7.综合测试
这个阶段的关键任务是通过各种类型的测试(及相应 的调试)使软件达到预定的要求。
8.软件维护
维护阶段的关键任务是，通过各种必要的维护活动使 系统持久地满足用户的需要。通常有四类维护活动. 改正性维护；适应性维护；完善性维护； 预防性维护；
传统的瀑布模型
按照传统的瀑布模型开发软件，有下述三个特点：
（1）阶段间具有顺序性和依赖性
（2）推迟实现的观点
清楚地区分逻辑设计与物理设计，尽可能推迟软件的 物理实现，是按照瀑布模型开发软件的一条重要的指导 思想。
（3）质量保证的观点
软件工程的基本目标是优质、高产。为了保证所开发 出的软件的质量，在瀑布模型的每个阶段都坚持下述的 两个重要做法：
由于瀑布模型几乎完全依赖于书面的规格说明， 有可能导致最终开发出的软件产品不能真正满足用 户的需要。
3.2 快速原型模型
所谓快速原型是快速建立 起来的可以在计算机上运行的 程序，它能完成的功能往往是 最终的软件产品所能完成的功 能的一个子集。如图所示（图 中实线箭头表示开发过程，虚 线箭头表示维护过程），按照 快速原型模型开发软件时，第 一步是快速建立一个能反映用 户主要需求的原型系统，让用 户在计算机上试用它，通过实 践来了解目标系统的概貌。
增量模型的另一个优点是，逐步增加产品功能可以使 用户有较充裕的时间学习和适应新产品，从而减少一个全 新的软件可能给客户组织带来的冲击。
使用增量模型的困难是，在把每个新的增量构件集成 到现有软件体系结构中时，必须不破坏原来已经开发出的 产品。
3.4 螺旋模型
软件开发几乎总要冒一定的风险。软件风险是任何软 件开发项目中都普遍存在的实际问题，项目越大，软件产 品越复杂，承担该项目所冒的风险也越大。软件风险可能 在不同程度上损害软件开发过程和软件产品质量。因此， 在软件开发过程中必须及时识别和分析风险，并且采取适 当措施以消除或减少风险的危害。
构建原型是一种能使某些类型的风险降至最低的方法。
螺旋模型集合了瀑 布模型和快速原型模型 的特点，并增加了风险 分析。螺旋模型的基本 思想是，使用原型及其 他方法以尽可能地降低 风险。理解这种模型的 一个简易方法，是把它 看作在每个阶段之前都 增加了风险分析过程的 快速原型模型，如图1.6 所示。
图1.6 简化的螺旋模型
2、软件过程
1 软件过程
软件工程过程是为了获得高质量软件所需要完 成的一系列任务的框架，它规定了完成各项任务的 工作步骤。
软件过程定义了运用软件开发方法的顺序、应该交付的文 档资料、为保证软件质量和协调变化所需要采取的管理措施 以及标志软件开发各个阶段任务完成的里程碑。为获得高质 量的软件产品，软件过程必须科学而且合理。软件过程是构 成软件工程方法学的一个重要的成分。
– 提供了在开发组织中分派任务和责任的纪律化方法 – 可控的日程和预算，提供满足用户需求的高质量产
品
• 过程产品
– Rational 公司开发和维护的过程产品
• 过程框架
– 可配置的过程 – 适用于不同规模的开发团队 – 适用于不同规模和不同复杂度的项目元素
● 每个阶段都必须完成规定的文档，没有交出合格的文 档就是没有完成该阶段的任务。完整、准确的合格文档不 仅是软件开发过程中各类人员之间相互沟通的媒介，也是 运行时期对软件进行维护的重要依据。
● 每个阶段结束前都要对该阶段所完成的文档（或程序 ）进行评审（或测试），以便尽早发现问题，及时改正错 误。事实上，如果没有在每个阶段结束前都进行评审，则 越是早期阶段犯下的错误，暴露出来的时间就越晚，排除 故障改正错误所需付出的代价也越高。因此，及时审查是 保证软件质量、降低软件成本的重要措施。
把软件产品分解成增量构件时，应该使构件的规模 适中，规模过大或过小都不好。最佳分解方法因软件产 品特点和开发人员的习惯而异。分解时惟一必须遵守的 约束条件是，当把新构件集成到现有软件中时，所形成 的产品必须是可测试的。
采用瀑布模型或快速原型模型开发软件时，目标都是 一次就把一个满足所有需求的产品提交给用户。增量模型 则与之相反，它分批地逐步向用户提交产品，每次提交一 个满足用户需求子集的可运行的产品。整个软件产品被分 解成许多个增量构件，开发人员一个构件接一个构件地向 用户提交产品。每次用户都得到一个满足部分需求的可运 行的产品，直到最后一次得到满足全部需求的完整产品。 从第一个构件交付之日起，用户就能做一些有用的工作。 显然，能在较短时间内向用户提交可完成一些有用的工作 的产品，是增量模型的一个优点。