迭代模型.docx
《迭代模型.docx》由会员分享，可在线阅读，更多相关《迭代模型.docx（22页珍藏版）》请在冰豆网上搜索。
迭代模型
耀邦软件规范
迭代型生命周期模型
版本0.2
Draft
配置管理
文档类别：
耀邦软件规范
文档名称：
迭代型生命周期模型
ID：
版本：
状态：
草稿
访问路径：
VOB：
ybsw\proc
模板：
ybsw-tmpl-word.dot-01
所有人：
SEPG
作者/创建时间：
批准人/批准时间：
[谁批准的]
修订历史：
日期
版本
说明
作者
2005-11-30
0.1
创建本文档，总体概念
2005-12-5
0.2
完成初稿
迭代型生命周期模型
1.简介
目的
本文档描述研发中心的迭代型软件生命周期，定义了该生命周期的阶段、目标及其产出物，作为项目开发的指南。
范围
本文档仅包含迭代型生命周期模型的定义及其各阶段的基本活动与输入、输出，但不包含各阶段活动的具体实现过程、方法与角色。
读者
项目管理人员应阅读本文档，理解文档中定义的生命周期模型的结构，并在此基础上制定项目的具体开发过程。
软件工程人员应阅读本文档，并依据生命周期各阶段的要求完成自己的工作。
2.模型定义
总体概述
总体模型视图
图1迭代型生命周期模型
模型简介
迭代型生命周期模型由螺旋型生命周期模型演进而来，所有按照迭代模型开发的软件项目都要经历一个从先启（Inception）->精化（Elaboration）->构建（Construction）->产品化（Transition）的开发过程（开发周期）；并完成项目管理、开发、支持等各项核心的活动。
完整的软件生命周期包含项目先启、精化架构、构建源码、产品化过渡等四个里程碑阶段（见上图顶部的横轴“工作流程—阶段”）；及各大阶段中划分的各次迭代（见上图底部的横轴“迭代”）。
项目管理、开发、支持等核心活动包括项目策划、监督管理；业务分析、需求开发、分析设计、编码实施、测试、发布与部署；软件配置与变更管理、软件质量保证；软件开发环境、软件过程环境等（见上图左列的竖轴）。
项目管理、开发、支持等核心活动贯穿整个项目生命周期，只是在不同阶段及迭代中各项活动的力度变化较大（见上图中部的分布曲线）。
里程碑阶段模型视图
图2迭代型生命周期阶段
模型基本特性
风险驱动的开发模式
软件开发天然地存在各种不确定性，如需求不明、需求变更、系统构架设计难予验证等等；而且项目通常都存在一定的工期压力，这些都是软件项目面临的风险，为了解决这些风险，迭代型生命周期模型继承螺旋模型的风险驱动的特性，没有像传统的瀑布模型，依照软件开发的工作内容来划分生命周期阶段，而是根据项目演进过程中主要风险的变化，将项目的生命周期分为四个主要阶段。
例如项目先启阶段要确定项目的目标，将项目重要业务风险、需求风险和技术风险问题予以解决，确保项目值得进行而且可以进行；而精化架构阶段的目标是建立系统构架的基线（基准），以便为构建源码阶段的主要设计和实施工作提供一个稳定的基础，换句话说，即是解决项目的架构风险。
所谓风险驱动，要求将风险最大的工作最早进行，我们可以看到项目先启阶段正是解决确保项目是否值得进行且可以进行这一最大风险；而精化架构阶段的架构风险则次之；进入构建源码和产品化过渡阶段时，意味着项目所有的重大风险已被解决。
掌握迭代型模型，首要的是掌握项目风险管理的技术。
里程碑
与项目生命周期四个主要阶段相对应，迭代型模型定义了四个里程碑，在每个阶段的结束点，描述了项目必须完成的任务与达到的状态（特别是风险变化的状态），并成为能否进入下一阶段的判断条件。
根据项目风险的演进与变化，四个里程碑被定义为：
项目目标里程碑（LifecycleObjectives）、项目架构基线里程碑（LifecycleArchitecture）、初始可交付里程碑（InitialOperationalCapability）、产品发布里程碑（ProductRelease）。
里程碑的意义在于为项目风险的评估提供显式的标准，阻止项目上阶段风险引入到下一阶段。
迭代的概念
为了进一步规避项目风险，通常根据需要在各里程碑阶段中划分一次或多次迭代开发过程，以滚动演进的方式分次实现里程碑目标。
一次迭代，根据其所处的阶段，将不同力度的业务分析、需求开发、分析设计、编码实现、测试与部署等开发活动按一种松散的顺序组合在一起。
在项目先启、精化架构阶段的迭代活动集中于项目管理、需求开发、设计等方面；而在构建源码阶段，则集中于设计、编码实现与测试等方面；到了产品化过渡阶段，其焦点则成了测试与部署等活动。
迭代概念的提出，很大程度上是为了便于实施进度控制。
每次迭代置于时间框方式的管理下，项目组必须优先保证迭代满足计划进度，并通过裁减迭代的内容范围来跟上进度期限。
注意迭代过程的最终目标仍是实现其所在里程碑阶段设定的目标。
比如某项目的架构设计难度很大，存在风险，于是在其精化架构阶段划分验证原型开发与系统构架优化两次迭代，这两次迭代的目的都是为了建立正确的构架基线，而此阶段的验证原型不能用于对用户的交付（这是源码构建和产品化过渡迭代才能做的事）。
为了赶工期，可以在源码构建阶段，根据产品功能优先级划分多次源码构建迭代，并将产品化过渡阶段提前与构建阶段的后续迭代重叠，分别向用户交付迭代演进版本。
需强调的是，产品化过渡阶段提前到与精化架构阶段重叠是有风险的。
项目的核心活动
为了完成软件项目，必须进行项目管理、开发、支持等各项核心活动。
传统的瀑布模型将需求开发、分析设计、编码实施、测试等开发活动固化，不能适应软件开发本身不断发现问题不断改进的天然特性，带来变更实施的高成本。
迭代模型与此相反，从上节模型图示中，可以看到这些开发活动贯穿整个项目生命周期，只是在不同阶段及迭代中各项活动的力度变化较大，但每次迭代理论上均可包含所有的管理、开发、支持核心活动。
从此角度看，迭代有点像一次小规模的瀑布模型过程，使得后续的迭代过程有机会改进之前迭代遗留下来的问题（如设计缺陷）及实现变更的需求。
然而正因为各次迭代过程设定的目标不同，各项活动在相应迭代过程中的执行力度也不同，例如在源码构建迭代中，系统架构设计的修改只能是微小与局部的，重大设计变更的出现，意味着应取消此迭代，将项目退回到精化架构阶段，并重新计划新的架构精化和源码构建迭代。
将迭代模型等同于多次退化的瀑布模型过程的重复是危险的，传统瀑布模型所体现的软件开发规律并未过时，明确清晰的需求基线，完整健壮的架构设计基线，之后才是细致认真的编码，严格全面的测试的顺序，迭代模型同样必须遵守。
每次迭代过程的结果，关注的是里程碑目标的实现得到一定程度的验证，进而确定相应的风险被解决。
迭代结果可以是经过系统测试的可发布源码，也可以是粗糙的架构原型，或者就是得到评审的SRS等文档，这取决于迭代过程所处的里程碑阶段。
这也是各次迭代理论上均可包含所有的开发核心活动的主要原因之一，例如以粗糙的架构原型验证架构基线，自然离不开编码实施、测试等活动。
另外，在项目先启阶段，为了让开发人员熟悉新的开发环境，同样也会导致一定的编码、测试等活动。
总之迭代过程中各项管理、开发、支持活动的计划完全由其实现的目标决定。
项目的演进开发
根据有关的项目开发策略，可以将产品功能需求分期予以实现。
前述的划分多次源码构建与产品化迭代无疑是其中一种不错的方法。
但是有些项目，其工期压力迫使留给精化架构阶段的时间太短而无法做出一个完整、稳定的架构基线，或者项目后期需求发生重大的变更，对于这些情况，同一开发周期中多次迭代的方法已不适用。
对此可以将项目划分为多个开发周期，第一个开发周期及后续的演进开发周期理论上均拥有项目先启、精化架构、构建源码、产品化过渡等四个里程碑阶段，但根据实际状况后续的演进开发周期可以省略项目先启阶段，以及只计划很短的精化架构迭代。
（注意开发周期与迭代过程的本质区别）
迭代的重叠
迭代模型的一个重要特性即是支持项目的并行开发。
从整个项目周期的角度，是通过各次迭代过程时间上的重叠来实现的，例如将多个产品化迭代与多个构建迭代的后续迭代重叠，以分别向用户交付迭代演进版本；而在迭代过程之中，则可以通过任务的逻辑划分来做到。
然而，这需要满足很多的条件，比如设计优良、健壮的体系架构，才使得将产品的功能需求分配到不同构建迭代过程中完成变得现实可行；又如只有层次分明、接口稳定的模块设计，才可能真正实现各模块的并行开发，虽然现在强大的软件配置管理工具可以从技术层面支持团队协同开发，但仍解决不了并行开发的根本问题。
实际上迭代模型是典型的以体系架构为中心的开发方法，没有健壮的体系架构，迭代最终只能退化成多次小瀑布模型过程的循环，真的成了“增量就是打补丁,迭代就是推倒重来”。
增量式集成
传统的瀑布模型中，采用大集成的模式，即到了单元测试之后才一次性地将各个分别开发、测试的单元集成到一起，这种模式常常给项目带来极大的困扰和风险。
迭代模型支持增量式集成的模式，在不同的迭代过程（主要是源码构建）中分别集成不同功能单元；在同一迭代过程中，多次增量集成新的功能特性，从而极大的降低了集成和构建风险。
核心活动与生命周期
项目管理活动
软件开发要顺利的进行，项目所有主要的活动都必须先有计划，并得到控制。
估计、策划、度量、监督和控制的过程，贯穿了整个软件生命周期。
Ø管理职责
项目管理的总体负责人为项目经理，承担项目策划、监督、控制、领导与协调工作；体系架构师（技术经理）主导技术管理；SQA主管或授权SQA工程师主导各项支持活动的管理。
（现有条件下，项目经理与体系架构师的角色可由同一人充当）
Ø里程碑控制
根据项目需求、工期限制、资源条件，估计项目的规模、工作量、时间，依此策划项目的软件开发与迭代过程。
软件开发计划将项目的整体开发过程划分为项目先启、精化架构、构建源码、产品化过渡四个阶段，并设定项目目标、项目架构基线、初始可交付、产品发布四个里程碑标准。
软件开发计划通常初步策划各阶段的迭代过程，确定各次迭代的基本目标（解决的主要风险）。
对整个开发周期加以严格的里程碑控制，通过里程碑评审（风险评估）决定项目是否进入下一阶段或被终止。
Ø迭代管理
根据软件开发计划，修正与细化各次迭代的具体目标与工作范围（如须解决的风险，将实现的需求项等），针对迭代目标，组织与裁减核心开发流程（包括业务分析、需求开发、分析设计、编码实现、测试、发布与部署等），策划具体的活动内容与任务，安排人力、物力资源的分配，设定具体的时间表等等。
与大粒度、不够精细的软件开发计划不同，迭代计划关注的时间短、策划的依据比较确定，由此对迭代过程采取时间框管理。
与里程碑控制不同，它以保证计划进度为首要目标，主要通过裁减迭代的任务范围，比如将任务推后到下次迭代，来跟上进度期限（增加人力的方式须谨慎考虑）。
本次迭代的执行结果，往往成为调整项目估计和策划下次迭代的经验参照和依据，使得下次迭代计划更为精细与切实可行。
项目开发活动
开发活动属于直接对项目产出有贡献的活动。
它包含业务分析、需求开发、分析设计、编码实现、测试、发布与部署等核心工作。
Ø开发活动的组织
各项开发活动按松散的逻辑顺序方式，以迭代为单位组织成便于管理的一次迭代过程，以实现迭代既定的目标。
迭代过程拥有风险解决目标，其下对应的是相关产出物，和为了做出这些产出物必须进行的有关开发活动；目标产出物与对应的开发活动构成迭代计划中的各项任务。
Ø核心开发流程
忽略各项开发活动在各迭代过程中的具体分布，逻辑上存在各自的工作流程。
各工作流程要么分配到多次迭代中分步完成，要么在各迭代中重复进行，或在一次迭代中全部做完。
核心工作流程中的各子活动的顺序关系、与产出物的对应关系，在各迭代中维持不变。
迭代策划的主要工作，就是根据迭代目标，组织和裁减相关核心工作流程，以实现之。
项目支持活动
软件开发质量的保证，项目产出物的管理等活动，对于项目的成败同样起关键作用，这些属于项目的支持活动范畴。
Ø软件质量保证
在项目主要任务结束时，其活动和产出物要接受相应的验证、评审，以确保软件过程被遵守、产出物符合规范。
“验证”指的是SQA组必须对该活动和产出物进行审计和批准。
Ø软件配置管理与变更控制
项目相关产出物都必须置于一定的配置管理之下，并在条件满足时基线化，以确保后续活动对其的正常使用。
软件过程管理
软件开发环境、软件过程环境等属于软件过程管理的范畴。
实施迭代过程
风险驱动的项目管理
软件项目区别于其它类型项目的主要特性就是其天然的高风险性。
软件需求不确定，架构的脆弱，编码质量难以控制，人员管理困难等，都是项目将面对的重大风险。
如何控制与解决这些风险，直接关系到项目的最终成败。
需求驱动的开发过程
在项目的执行过程中，所有的活动（任务）都是为了实现某项需求，不针对任何需求的任务是没有意义的，因此项目的开发过程是由需求驱动的。
项目的估计、策划必须根据项目的需求，从而保证项目的实施过程，就是满足与实现需求的过程。
所谓需求驱动，包括两个方面：
●项目产出物对象间的需求追踪链，即维护需求——〉体系结构——〉详细设计——〉实现——〉验证一条链的关系。
●需求驱动的项目开发管理活动，即维护需求——〉估计——〉策划——〉实施一条链的关系。
迭代模型中，此过程的主要单位是一次完整的迭代。
以体系架构为中心的开发方法
3.生命周期阶段定义
项目先启阶段
目的
力求所有涉众（项目相关人员）对软件开发的目标达成一致共识。
解决项目的商业与需求风险，确保项目的商业理由（值得做）与可行性（能够做）。
目标
✧确定项目开发范围与边界，包括软件产品的操作前景、验收标准，产品中包括什么与不包括什么
✧识别系统中的关键用例（给用户提供的主要功能），这些关键应用场景将对系统最终设计起决定性影响
✧针对系统主要应用场景，展示至少一种或以上的满足条件的候选软件架构
✧估计项目总体的成本与开发时间
✧估计项目的风险
✧准备项目的管理、开发、支持环境
进入准则
当以下条件满足时，可以开始启动一个软件项目：
✧高级经理指派项目经理并下达《软件项目任务书》
✧项目的初始需求、合同或预研报告作为项目任务书的附件被提交
输入
产出物
内容
所有者
状态
软件项目任务书
SOW：
StatementofWork
指派项目经理；描述项目的初始需求
高级经理
经高级经理和项目经理共同签署确认
项目相关的背景、合同、技术参考资料
企业的产品发展规划；项目的背景资料；相关的商业材料（售前投标书、合同等）；项目建议书、预研报告等
主要活动
项目先启阶段的主要活动包括：
✧规格化项目开发范围与高层需求
这包含识别系统的应用和操作环境，最重要的软件需求和相关限制，并由此能得出最终产品的验收标准。
✧业务分析与软件需求获取（可选）
对于较新的业务领域，需要获取领域知识，分析用户的业务环境和组织结构，识别关键业务流程，并根据业务需求抽象软件需求（确定业务流程中由软件实现的自动化步骤）。
✧策划与准备商业理由
综合分析与评估各候选方案，包括风险管理、项目人员配备、项目计划，以及项目成本、进度及收益率的折衷考虑等，从而明确项目的商业价值和风险。
✧综合分析与规划候选软件架构
对高层的架构设计进行折衷，并考虑各软件构件是否自制、外购或复用的选择，从而在此基础上估算项目的成本、进度和资源要求。
✧领域分析与解决方案参考（可选）
局限于每个项目的需求通常是不确定的，然而其所面对的业务领域总体上却是相对稳定的。
业务角色、实体关系、关键业务流程都是领域中变化较慢的部分，将这些对象抽象出来，形成领域模型，有助于设计出最健壮的软件架构。
面向对象的分析方法，其优势通常都体现在领域对象的抽取上。
很多业务和技术领域，已有大量现存的研究成果，和解决方案可以参照，甚至有商业产品可供选择，这往往都是加快项目的关键所在。
✧验证软件需求和候选软件架构
本阶段的目标在于通过概念验证来确认项目的可行性。
这可以采用能够模拟需求的建模方式；或开发概念原型（通常是项目关键算法、技术解决方案），用来探索被认为是高风险的领域；当然也可能是界面原型，用来验证与获取用户需求。
在先启阶段的原型开发只限于确定解决方案的可行性—解决方案将在精化和构建阶段予以实现。
✧准备项目的管理、开发、支持与过程环境
评估项目和组织架构，构建开发团队，选择相关工具，裁减或改进项目的管理、开发、支持等过程。
产出物
项目先启阶段的产出物包括：
产出物
内容
所有者
状态
前景与范围文档
V&S：
Vision&Scope
定义系统的核心需求，软件产品的关键特性，以及主要约束
（用UML模型表达关键用例）
需求工程师
高级经理批准
商业理由或可行性分析报告
FAR：
FeasibilityAnalisysReport
分析项目的市场和技术前景；对项目成本、工期的初始估计；分析项目的风险以及规避策略；项目备选软件架构与解决方案
（用UML模型表达初始的软件层次架构、构件视图或部署视图）
开发方案
DC：
DevelopmentCase
裁减或改进的项目管理、开发、支持等过程；包括工具的选择、文档模型的模板准备；开发平台准备；软件配置管理方案；软件质量保证方案等等
软件开发计划
SDP：
SoftwareDevelopmenPlan
明确项目的目标、背景、范围、约束条件；确定项目的团队架构；确定开发、支持工具；初步识别风险；确定项目里程碑和初步的迭代周期
项目经理
高级经理批准
迭代计划
IP：
IterationPlan
根据迭代周期，制定第一次迭代（项目先启）的详细计划，包含迭代目标、人员安排、详细的时间表；制定架构精化阶段的详细迭代计划
项目经理
可选产出物
内容
所有者
状态
业务分析文档
BAD：
BusinessAnalysisDocument
分析用户的业务环境和组织结构；识别关键业务流程；根据业务需求抽象软件需求
（用UML模型表达关键业务用例、业务角色及关系、业务顺序图）
里程碑评估标准
先启阶段末是第一个重要的项目里程碑，即项目目标里程碑。
此时，必须审查项目的生命周期目标，并决定继续进行项目还是取消项目。
✧涉众（项目相关人员）对软件开发的目标，和成本、工期估计达成一致共识
✧涉众认可正确的软件需求已被识别，并对这些需求有共同的理解
✧对成本、工期估计，开发优先级顺序，项目风险，以及开发过程是否适合成一致意见
✧确定所有风险已被识别，并且有相应的风险减轻策略（需求风险、商业风险、项目可行性风险已被解决）
精化架构阶段
目的
开发软件的架构基线，为后续构建阶段的详细设计、编码实现提供稳定的开发基础。
软件架构必须基于系统的关键需求（对构架具有决定性影响）和对项目风险（技术或工期等）的评估结果。
构架的稳定性可以通过一个或多个构架原型来做评估。
目标
✧确保软件构架、需求和计划足够稳定，并且风险得到充分缩减，从而能够较有把握地确定完成开发所需的成本和工期。
对大多数项目来说，通过此里程碑也就意味着从轻量级、快速和低风险的运作阶段进入到高成本、高风险的运作阶段。
✧处置所有显著的构架性的项目风险
✧建立确定的软件构架基线
通过分析影响构架的系统应用场景，来确定软件构架。
这些场景通常揭示了项目最高的技术风险。
✧开发具备产品质量的构件的演进式原型，或开发一个或多个抛弃式的探索性原型，来消减特定风险，例如：
a）设计与需求的折衷
b）构件的复用
c）产品可行性或向投资者、客户和最终用户进行演示
✧证明基线化的软件构架将以适当工期、合理的成本实现系统需求
✧建立项目的管理、开发、支持环境
进入准则
当项目目标里程碑通过后，可以进入架构精化阶段
✧项目开发目标与范围被确定；业务、需求风险被解决
✧初步制定软件开发计划；制定了详细的架构精化迭代计划
输入
项目先启阶段的产出
主要活动
架构精化阶段的主要活动包括：
✧修正与完善项目前景与范围
根据新获得的信息改进前景文档，对决定软件构架和计划决策的关键用例确立稳固的理解。
✧细化与完善软件需求
完成大部分功能需求（80%的系统用例，并包含所有关键用例）；和主要的非功能性需求（质量需求等）。
✧尽可能早地定义、确认和基线化软件构架
根据软件应用环境、需求，选择合适的软件架构模式（如Client/Server、Browser/Server、Corba架构等）；识别主要的系统组成；划分合理的层次与构件组织结构。
分析与抽象系统主要的实体、控制与边界类，这通常对应为业务实体、业务逻辑和应用界面。
最终将分析的结果，转化为具体的设计，得到系统的架构设计模型。
✧领域建模与软件重用考虑（可选）
企业在软件产品的开发组织上，可以选择产品线或软件重用的策略。
健壮的应用软件架构通常基于稳定的领域架构之上，真正的软件重用也是领域中相对独立的构件重用。
✧改进软件构架，定义与选择开发构件
评估系统潜在的组成构件，并做自制、外购或复用的决策，以确定源码构建阶段的实现成本和进度。
需要对所选构件进行集成，并于主要应用场景下进行评估。
经过这些活动后得到的经验，有可能导致重新设计架构，考虑替代的设计或重新分析需求。
✧运用关键用例验证软件构架
通过开发架构原型，或白板演示等方式，执行关键用例，以验证软件构架。
另外还应对软件架构文档进行严格的复核与评审。
✧为源码构建阶段制定详细的迭代计划并予基线化
综合需求范围、优先等级、架构风险，确定源码构建阶段的迭代周期，制定详细的迭代计划。
✧完善项目的开发方案，建立项目的管理、开发、支持与过程环境
建设开发团队，安装相关工具，搭建开发与支持环境，完成项目的管理、开发、支持等过程的裁减。
产出物
精化架构阶段的产出物包括：
产出物
内容
所有者
状态
前景与范围文档
V&S：
Vision&Scope
修正与完善系统的核心需求，软件产品的关键特性，以及主要约束
（用UML模型表达关键用例）
需求工程师
高级经理批准
需求规格说明书
SRS：
SoftwareRequirementSpecification
大部分功能需求（80%的系统用例，并包含所有关键用例）；和主要的非功能性需求（质量需求等）
（用UML模型表达基本用例）
软件架构文档
SAD：
SoftwareArchitectureDocument
描述决定软件构架的关键用例；软件层次架构；系统的逻辑视图（主要实体对象、业务逻辑）；设计元素；或进程视图和部署视图
（用UML模型表达软件层次架构、主要构件包、分析模型、设计模型、构件视图或部署视图）
开发方案
DC：
DevelopmentCase
完成项目管理、开发、支持等过程的裁减或改进；制定详细的设计规范和指南；制定编码规范和指南；制定软件配置管理具体方案；完成软件质量保证方案等等
软件开发计划
SDP：
SoftwareDevelopmenPlan
详细估计项目的规模、工作量、时间和成本；定义系统的主要组成构件，并确定获取方式（自制、外购或复用）；定义产品的验收标准，并确定要执行的产品验收任务；完成主要的工作分解结构，确定项目详细的迭代周期；制定软件配置管理计划
项目经理
测试计划
TP：
TestPlan
描述系统的测试范围（功能测试、性能测试等）；测试验收标准；测
升级会员 