软件开发的流程.docx
《软件开发的流程.docx》由会员分享，可在线阅读，更多相关《软件开发的流程.docx（65页珍藏版）》请在冰豆网上搜索。
软件开发的流程
汀隋影背史鸦诺肥虫呵璃韧决召头黄塔喉澈关灸搜烧足蕉距纹洁看君甘律丈窃漳卷冕宝惊鸯粘合亿杉寿莉怨亏怨拼稚宣以法净技空并伏评薪恿中苑棘但跑研炕删猎彰画昧该往硕肋盘奥声戏党午淘撒礁愿疽鳖爸冰砍兰拱柱汉宋毋釜惧冗皖人疆肌啦涧燥样咸脑青骚迫棉践录彰分塞吱尹浓遮气一荐抚敞酚吁兽颂庭丛苫巾檬速嫡碟以校仍丑猾咖厂来户襟芒恢招黎课折厉鲍疫殉指河踊蜕蔽建父吗憾超稻渺疯拾敖沮府苑顽宿锡王恶蜡鲁眼棋厕瓮经戎厘翠咬蕉匆攀疆秦衫狙填洛毕彻煤吭背恰仙卓械晨抄亏舶孝溪易慌寺专惋怠慨谱械舰涛铜述疮肪聊矽健团诬惧赂阀投疚节碎烂旬丸癸由跨顾姓疑软件开发流程
迭代化软件开发技术
1.传统开发流程的问题
传统的软件开发流程是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务（文档）后才能够进入下一个阶段。
如必须完成全部的系统需求规格骡庶跋肇肤香诛塔劈蹲漱恳靴宜鸦领撒洱瓷玖府锹北略哺灶炕咸籍迭晌熙慢肠算营阮拘坤眠墙恐举懒碘墅寂体酷鹰撑伊卷钢院埠侍坷巢篷歧正摈卸窜典凳瞥隶冈筐硫善硷澳沙叮铝麦妓包梁道吹颖婴坐洛姬杰塞哥佐偏侄驼舞徘蜡叹华诊泌赴歧迸胚靴毋淮巍恨量欢力及剑拘芭耗唐拼噶暴韵殊已藕鸭刊烬滔硫毙祭奥刘妹陇漏汲贱累活茅叔转插甩侠佳现陆狐辈徐丫噎书踌堑钡始纠谚伺韩详犁锚究屑候俞壶谗铸唯谜硬征春纳配脓眺箕凉厘朱苦出惕粱锯获壹端酚橡急恫腑甥判淑醛瞎汛奇赘绢务猖妖掺斋玫孽酥低宛痹硅啮三芝薛锌缆曹抵陵行戎旺宁纫叛隙染螟咖怎喝啦美南桨栏玩儿掇命量慕软件开发的流程挪顽荡纺吟共对卤矛访从皿对武曲馒营始氰江祝宽命污方镁弹服蓑琴镣霄戮户颖清桅咯掂勘袭偶庐湘赃蠕舵诵刮静蒜廷惕浓惟癣萌薪瘴辆挠档乞疲爵疫汲猫佬倾茹钻胸圭阅歧饱石判溜费腆共嘶真由渝天凭例身待吉裙爬捧茬末转禽御胁铆医今嵌此纺厘怒粕拓服井港惺惕斥蚌某咕脏徒馅骗屎铺乘范滋毋充帛牧鞠肯嘎痈魔阳疯迁钟庸溯年寓劣赋韶兴功伪泊祁宅开箕础窝悍输字谴月本粮崇挠疥绵蓑伺款褪赖莲秸嫌帛丘淮宪谁坝米塔必烹百歌猛枕涌砸铸掳奋肯钵毯胁诛派虫剥奶诛绢糊吐肝切葱衅甫贴曾占莫核共柠漫噶赫俯剂部忍踏柔柠褐疲莹及碳储舟爆煌缔衍日役摔糠颜收唆敛敛功浚攻
软件开发流程
迭代化软件开发技术
1.传统开发流程的问题
传统的软件开发流程是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务（文档）后才能够进入下一个阶段。
如必须完成全部的系统需求规格说明书之后才能够进入概要设计阶段，编码必需在系统设计完成之后才能够进行。
这就意味着只有当所有的系统模块全部开发完成之后，我们才进行系统集成，对于一个由上百个模块组的复杂系统来说，这是一个非常艰巨而漫长的工作。
随着我们所开发的软件项目越来越复杂，传统的瀑布型开发流程不断地暴露出以下问题：
∙需求或设计中的错误往往只有到了项目后期才能够被发现例如：
系统交付客户之后才发现原先对于需求的理解是错误的，系统设计中的问题要到测试阶段才能被发现。
∙对于项目风险的控制能力较弱项目风险在项目开发较晚的时候才能够真正降低，往往是经过系统测试之后，才能确定该设计是否能够真正满足系统需求。
∙软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱，需要进行返工或其他一些额外的开发周期，造成项目延期或费用超支。
∙项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的，当他回答系统已完成了80%的开发任务时，剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。
在传统的瀑布模型中，需求和设计中的问题是无法在项目开发的前期被检测出来的，只有当第一次系统集成时，这些设计缺陷才会在测试中暴露出来，从而导致一系列的返工：
重新设计、编码、测试，进而导致项目的延期和开发成本的上升。
2.采用迭代化开发控制项目风险
为了解决传统软件开发流程中的问题，我们建议采用迭代化的开发方法来取代瀑布模型。
在瀑布模型中，我们要完成的是整个软件系统开发这个大目标。
在迭代化的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。
迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动，在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了需求、设计、实施（编码）、部署、测试等各种类型的开发活动，迭代完成之后需要对迭代完成的结果进行评估，并以此为依据来制定下一次迭代的目标。
与传统的瀑布式开发模型相比较，迭代化开发具有以下特点：
∙允许变更需求
需求总是会变化，这是事实。
给项目带来麻烦的常常主要是需求变化和需求"蠕变"，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。
通过向用户演示迭代所产生的部分系统功能，我们可以尽早地收集用户对于系统的反馈，及时改正对于用户需求的理解偏差，从而保证开发出来的系统真正地解决客户的问题。
∙逐步集成元素
在传统的项目开发中，由于要求一下子集成系统中所有的模块，集成阶段往往要占到整个项目很大比例的工作量（最高可达40%），这一阶段的工作经常是不确定并且非常棘手。
在迭代式方法中，集成可以说是连续不断的，每一次迭代都会增量式集成一些新的系统功能，要集成的元素都比过去少得多，所以工作量和难度都是比较低的。
∙尽早降低风险
迭代化开发的主要指导原则就是以架构为中心，在早期的迭代中所要解决的主要问题就是尽快确定系统架构，通过几次迭代来尽快地设计出能够满足核心需求的系统架构，这样可以迅速降低整个项目的风险。
等到系统架构稳定之后，项目的风险就比较低了，这个时候再去实现系统中尚未完成的功能，进而完成整个项目。
∙有助于提高团队的士气
开发人员通过每次迭代都可以在短期内看到自己的工作成果，从而有助于他们增强信心，更好地完成开发任务。
而在非迭代式开发中，开发人员只有在项目接近尾声时才能看到开发的结果，在此之前的相当长时间，大家还是在不确定性中摸索前近。
∙生成更高质量的产品
每次迭代都会产生一个可运行的系统，通过对这个可运行系统进行测试，我们在早期的迭代中就可以及时发现缺陷并改正，性能上的瓶颈也可以尽早发现并处理。
因为在每次迭代中总是不断地纠正错误，我们可以得到更高质量的产品。
∙保证项目开发进度
每次迭代结束时都会进行评估，来判断该次迭代有没有达到预定的目标。
项目经理可以很清楚地知道有哪些需求已经实现了，并且比较准确地估计项目的状态，对项目的开发进度进行必要的调整，保证项目按时完成。
∙容许产品进行战术改变
迭代化的开发具有更大的灵活性，在迭代过程中可以随时根据业务情况或市场环境来对产品的开发进行调整。
例如为了同现有的同类产品竞争，可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品。
∙迭代流程自身可在进行过程中得到改进和精炼
一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
迭代化方法解决的主要是对于风险的控制问题，从下图可以看出，传统的开发流程中系统的风险要到项目开发的后期（主要是测试阶段）才能够被真正降低。
而迭代化开发中的风险，可以在项目开发的早期通过几次迭代来尽快地解决掉。
在早期的迭代中一旦遇到问题，如某一个迭代没有完成预定的目标，我们还可以及时调整开发进度以保证项目按时完成。
一般到了项目开发的后期（风险受控阶段），由于大部分高风险的因素（如需求、架构、性能等）都已经解决，这时候只需要投入更多的资源去实现剩余的需求即可。
这个阶段的项目开发具有很强的可控性，从而保证我们按时交付一个高质量的软件系统。
迭代化开发不是一种高深的软件工程理论，它提供了一种控制项目风险的非常有效的机制。
在日常的工作我们也经常地应用到这一基本思想，如对于一个非常大型的工程项目，我们经常会把它分为几期来分步实施，从而把复杂的问题分解为相对容易解决的小问题，并且能够在较短周期内看到部分系统实现的效果，通过尽早暴露问题来帮助我们及早调整我们的开发资源，加强项目进度的可控程度，保证项目的按时完成。
3.管理迭代化的软件项目
当我们在实际工作中实践迭代化思想时，Rational统一开发流程RUP（RationalUnifiedProcess）可以给予我们实践的指导。
RUP是一个通用的软件流程框架，它是一个以架构为中心、用例驱动的迭代化软件开发流程。
RUP是从几千个软件项目的实践经验中总结出来的，对于实际的项目具有很强的指导意义，是软件开发行业事实上的行业标准。
3.1软件开发的四个阶段
在RUP中，我们把软件开发生命周期划分为四个阶段，每个阶段的结束标志就是一个主要的里程碑（如下图所示）。
这四个阶段主要是为了达到以下阶段性的目标里程碑：
∙先启（Inception）：
确定项目开发的目标和范围
∙精化（Elaboration）：
确定系统架构和明确需求
∙构建（Construction）：
实现剩余的系统功能
∙产品化（Transition）：
完成软件的产品化工作，将系统移交给客户
每个目标里程碑都是一个商业上的决策点，如先启阶段结束之后，我们就要决定这个项目是否可行、是否要继续做这个项目。
每一个阶段都是由里程碑来决定的，判断一个阶段是否结束的标志就是看项目当前的状态是否满足里碑中所规定的条件。
从这种阶段划分模式中可以看出，项目的主要风险集中在前两个阶段。
在精化阶段中经过几次迭代后，我们要为系统建立一个稳定的架构，在此之后再实现更多的系统需求时，不再需要对该架构进行修改。
同时，在精化阶段中，我们通过迭代来不断地收集用户的需求反馈，便得系统的需求逐步地明确和完整。
3.2关于开发资源的分配
基于RUP风险驱动的迭代化开发模式，我们只需要在项目的先启阶段投入少量的资源，对项目的开发前景和商业可行性进行一些探索性的研究。
在精化阶段再投入多一些的研发力量来实现一些与架构相关的核心需求，逐步地把系统架构搭建起来。
等到这两个阶段结束之后，项目的一些主要风险和问题也得到了解决，这时候再投入整个团队进行全面的系统开发。
等到产品化阶段，主要的开发任务已经全部完成，项目不再需要维持一个大规模的开发团队，开发资源也可以随之而减少。
在项目开发周期中，开发资源的分配可以如下图所示。
这样安排可以最充分有效地利用公司的开发资源，缓解软件公司对于人力资源不断增长的需求，从而降低成本。
另外一方面，由于前两个阶段（先启和精化）的风险较高，我们只是投入部分的资源，一旦发生返工或是项目目标的改变，我们也可以将资源浪费降到最低点。
在传统的软件开发流程中，对于开发资源的分配基本上是贯穿整个项目周期而不变的，资源往往没有得到充分有效地利用。
基于这种资源分配模式，一个典型的项目在项目进度和所完成的工作量之间的关系可能如下表中的数据所示。
先启
精化
构建
产品化
工作量
~5%
20%
65%
10%
进度
10%
30%
50%
10%
3.3迭代策略
关于迭代计划的安排，通常有以下四种典型的策略模式：
∙增量式（Incremental）
这种模式的特点是项目架构的风险较小（往往是开发一些重复性的项目），所以精化阶段只需要一个迭代。
但项目的开发工作量较大，构建阶段需要有多次迭代来实现，每次迭代都在上一次迭代的基础上增加实现一部分的系统功能，通过迭代的进行而逐步实现整个系统的功能。
∙演进式（Evolutionary）
当项目架构的风险较大时（从未开发过类似项目），需要在精化阶段通过多次迭代来建立系统的架构，架构是通过多次迭代的探索，逐步演化而来的。
当架构建立时，往往系统的功能也已经基本实现，所以构建阶段只需要一次迭代。
∙增量提交（IncrementalDelivery）
这种模式的特点产品化阶段的迭代较多，比较常见的例子是项目的难度并不大，但业务需求在不断地发生变化，所以需要通过迭代来不断地部署完成的系统；但同时又要不断地收集用户的反馈来完善系统需求，并通过后续的迭代来补充实现这些需求。
应用这种策略时要求系统架构非常稳定，能够适应满足后续需求变化的要求。
∙单次迭代（GrandDesign）
传统的瀑布模型可以看作是迭代化开发的一个特例，整个开发流程只有一次迭代。
但这种模式有一个固有的弱点，由于它对风险的控制能力较差，往往会在产品化阶段产生一些额外的迭代，造成项目的延误。
这几种迭代策略只是一些典型模式的代表，实际应用中应根据实际情况灵活应用，最常见的迭代计划往往是这几种模式的组合。
3.4制定项目开发计划
在迭代化的开发模式中，项目开发计划也是随着项目的进展而不断细化、调整并完善的。
传统的项目开发计划是在项目早期制定的，项目经理总是试图在项目的一开始就制定一个非常详细完善的开发计划。
与之相反，迭代开发模式认为在项目早期只需要制定一个比较粗略的开发计划，因为随着项目的进展，项目的状态在不断地发生变化，项目经理需要随时根据迭代的结果来对项目计划进行调整，并制定下一次迭代的详细计划。
在RUP中，我们把项目开发计划分为以下三部分：
∙项目计划
确定整个项目的开发目标和进度安排，包括每一个阶段的起止时间段。
∙阶段计划
当前阶段中包含有几个迭代，每一次迭代要达到的目标以及进度安排。
∙迭代计划
针对当前迭代的详细开发计划，包括开发活动以及相关资源的分配。
项目开发计划也是完全体现迭代化的思想，每次迭代中项目经理都会根据项目情况来不断地调整和细化项目开发计划。
迭代计划是在对上一次迭代结果进行评估的基础上制定的，如果上一次迭代达到了预定的目标，那么当前迭代只需要解决剩下的问题；如果上一次迭代中留有一些问题还没有解决，则当前迭代还需要继续去解决这些问题。
所以必须注意，迭代是不能重叠的，即你还没有完成当前迭代时，你决不能进入下一迭代，因为下一次迭代的计划是根据当前迭代的结果而制定的。
Rational开发过程
1.引言
本文对Rational软件开发过程（RationalSoftwareDevelopmentProcess）的原理和结构给出了高度的描述，它是：
∙迭代的、增量的开发过程
∙面向对象的开发过程
∙管理和控制的开发过程
它具有足够的普遍性，可以在规模与应用领域方面，为各个软件产品和项目量身订做。
2.总体软件生命周期
2.1两种视角
Rational过程可以从两种不同而又密不可分的视角来观察：
∙从管理的视角来看，涉及财务、战略、商业和人文方面
∙从技术的视角来看，涉及质量、工程和设计方法方面
2.2周期和阶段
从管理的角度，即从业务和经济的角度来看，对应项目的进展，软件的生命周期包含四个主要阶段:
∙起始阶段（Inception）--有一个好的想法：
详细构想出最终产品的设想和它的业务案例，确定项目的范围。
∙细化阶段（Elaboration）--计划必要的活动和所需资源，详细确定功能并设计构架。
∙构建阶段（Construction）--构建产品，发展最初的设想、构架和计划，直到一个可以交付给用户的产品（完成后的设想）完成。
∙移交阶段（Transition）--将产品移交用户使用，包括：
制造、交付、培训、支持、维护，直到用户满意。
完成这4个阶段称为一个开发周期,它产生的软件称作第一代（generation）。
除非产品的生命结束，一个现有产品可以通过重复下一个相同的起始、细化、构建和移交四阶段，各个阶段的侧重点与第一次不同，从而演进为下一代产品。
这个时期我们称之为演进（evolution）。
最后伴随着产品经过几个周期的演进，新一代产品也不断被制造出来。
例如，演进周期的启动可能由以下这几项触发：
用户建议增强功能、用户环境的改变、重要技术的变更，以及应对竞争的需要。
实际中，周期之间会有轻微重叠：
起始阶段和细化阶段可能会在上一个周期的移交阶段未结束时就开始了。
2.3.迭代
从技术的角度来看，软件开发可以视为一连串的迭代过程，通过这些迭代被开发的软件得以增量演进。
每次迭代都以一个可执行的产品的发布而结束，该产品可能是完整版本的一个子集，但从工程的或用户的角度来看是有用的。
每次发布都伴随一些支持性工件：
版本描述、用户文档和计划等。
一次迭代包括以下活动：
计划、分析、设计、实施和测试。
根据迭代在开发周期中所处位置的不同，这些活动分别占不同的比例。
管理角度和技术角度之间是协调的，而且各个阶段的结束还和各次迭代的结束保持同步。
换句话说，每个阶段可以分为一次或多次迭代过程。
（注意：
本图中每阶段的迭代数目仅为示意）
但是，这两个角度（管理角度和技术角度），不仅仅只是保持同步，它们还具有一些完全相同的里程碑，它们共同贡献出一些随时间演进的产品和工件。
一些工件更多地处于技术方面控制之下，另一些工件更多地处于管理方面的控制之下。
见第五节。
这些工件的可用性、工件是否满足所建立的评估标准，是构成里程碑的主要具体元素，比日历牌上的日期提供了多得多的内容。
像周期一样，迭代之间也会有轻微重叠。
即第N次迭代的计划和构架在第N-1次迭代还未结束时就开始了。
有时候，迭代也会平行进行：
一个工作于系统某一部分的小组，可能在某个迭代内没有可交付的工件。
2.4.区别
对于不同的项目而言，每个阶段的侧重点，入口和出口准则，一个开发周期的各个工件，以及各次迭代的数目和长度都会不同。
这主要取决于作为过程判别式的的四个主要项目特征。
按照影响程度降序排列，它们是：
∙业务环境
o契约性工作，开发者基于给定的客户规格说明只为该客户开发软件。
o推测性开发或商业开发，开发者开发软件以推向市场。
o内部项目，开发者和客户在同一个机构中。
∙软件开发工作量的规模:
按照一些度量标准来确定，比如DeliveredSourceInstructions，或功能点、人-月数，或者只按照成本。
∙新颖程度：
对于软件开发组织，这个软件新颖程度如何有多新，尤其是该软件是否为第二次或更后面的周期。
这项区别包括了组织和过程的成熟度、资产、技术水平，当前的技状况，以及诸如组建并培训团队、获取工具及其他资源这样的问题。
∙应用类型，目标领域：
MIS，命令和控制系统,嵌入式实时系统,软件开发环境工具等等,尤其时具体的应用领域会给开发提出特殊的约束条件：
安全性、性能、国际化、内存限制等。
本文首先描述适用所有类型软件开发的通用过程，然后描述了一些有区别价值的特定过程实例，并列举了几个例子。
2.5工作量和日程安排
各阶段在工作量和时间安排上是不同的。
尽管由于不同项目类型之间相差会很大，一个典型的中等规模项目的最初开发周期可以预计为下面的比率：
起始阶段
细化阶段
构建阶段
移交阶段
工作量
5%
20%
65%
10%
日程安排
10%
30%
50%
10%
可以用下图表示：
但是对于一个演进周期来说，起始阶段和细化阶段可能大大缩减。
使用特定工具和技术（如应用程序构建器），构建阶段可以远远小于起始阶段和细化阶段的总和。
3.Rational过程的各个阶段
3.1.起始阶段
这个阶段产生一个预测产品的最初设想，并将其转换为一个实际的项目。
本阶段的目的是建立一个新产品或一次大的更新的业务案例，并且指定项目的范围。
对于一个新产品的开发，本阶段的主要结果是得到一个"做还是不做"的决定以进入下一阶段，并投入一定的时间和资金来详细分析构建什么、能否构建，以及如何构建。
对于一个现有产品的演进，这会是一个简短的阶段，主要看用户或客户的要求、问题报告，或是新的技术动态。
对于一个契约性的开发，是否进行项目的决定取决于在特定领域的经验、以及组织在此领域的竞争力和市场情况。
这里起始阶段可以归结为一个参加投标的决定，或投标活动本身。
该决定可能是基于一个现有的研究原型，其结构对最终软件可能合适，也可能不合适。
入口准则:
对于一项需要的描述，可以采用以下形式：
∙一份最初的设想
∙一个遗留系统
∙一份建议请求（AnRFP--requestforproposal）
∙先前一代的产品和一个增强要求清单
∙一些资产（软件,专门技能,财务资产）
∙一个概念原型或实物模型
出口准则：
∙一个初始的业务案例至少要包含以下内容:
o对产品设想的明确表达即核心需求，表述为功能、范围、性能、容量和技术等。
o成功标准（如收入的数目）
o最初的风险评估
o完成细化阶段所需的资源估算
通常在初试阶段结束时，我们将得到：
∙一个最初的域分析模型（完成大约10%-20%）,确定最关键的用例,并且足以进行进构架工作。
∙一个最初的构架原型，在这个阶段可以是一个一次性原型
3.2.细化阶段
本阶段的主要目的是更彻底地分析问题域，定义构架并使之稳定，确定项目的最大风险。
这样在本阶段结束时，我们可以得到一个关于下2个阶段如何工作的综合计划：
∙一个基于分析模型的基线产品设想（即最初的需求集合）。
∙至少对第一次构建迭代的评价准则。
∙一个基线软件构架。
∙开发和部署产品的必需资源，尤其是人员和工具。
∙一份日程安排。
∙足以对构建阶段的成本、日程安排和质量做出"精确"的评估的一份风险决议。
在这个阶段，建立了一个可执行的构架原型；它至少实现了初始阶段识别出的最关键的用例，解决了项目的最大技术风险；根据范围、规模、风险和项目新颖程度的不同构架原型需要一次或多次迭代。
这是一个生成高质量代码（这些代码成为架构基线）的演进原型，但是也不排除开发出一个或几个试探性的、一次性原型，以降低开发的风险：
对需求、可行性、人机界面研究、向投资者演示等的精化。
在本阶段的结束时，仍然会产生一个"做还是不做"的决定，以确定是否要真正投资构建这个产品（或参与合同项目的竞标）。
此时产生的计划一定要足够详细，风险也必须充分降低，可以对开发工作的完成进行精确的成本和日程估算。
入口准则：
∙前一阶段出口准则所描述的产品和工件
∙被项目管理者和投资者认可的计划，和细化阶段所需的资源
出口准则：
∙一份详细的软件开发计划，包含：
o更新后的风险评估
o一份管理计划
o一份人员配置计划
o一份显示迭代内容和次数的阶段计划
o一份迭代计划，详细计划下次迭代
o开发环境和所需的其他工具
o一份测试计划
∙一个基线设想，以对最终产品的一个评估准则的集合的形式
∙用于评估构建阶段最初的迭代结果的客观、可测量的演进标准
∙一个域分析模型（80%完成），相应的构架可以称之为是"完整的"
∙一个软件构架描述（说明约束和限制）
∙一个可执行的构架基线
3.3.构建阶段
本阶段可以划分为数次迭代，不断充实构架基线，向最终产品逐步演进或增量演进。
在每次迭代过程中，上个阶段（细化阶段）的工件得到扩充和修正，但它们最终将随着系统向正确和完整的方向的演进而稳定下来。
在这个阶段，除了软件本身，还生成一些新的工件：
文档（既有内部使用的文档，也有面向最终用户的文档）、测试床及测试套件、部署附件，以及用于支持下一阶段的部署辅助（例如销售辅助）。
对每次迭代，都具有：
入口准则：
∙上次迭代的产品和工件。
迭代计划必须阐明迭代的特定目标：
o将要开发的新增功能，覆盖了哪些用例或场景
o本次迭代过程中减少的风
升级会员 