迭代和增量的优点 允许变更需求:需求总是会变化,这是事实。 逐步集成元素:集成并不只是简单的“一锤定音”。在迭代式方法中 集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40%的那段较长的、不确定的且棘手的时期,现在分散到六至九个 集成部分中,每一部分要集成的元素都比过去少得多。 及早降低风险:因为风险一般只有在集成阶段才能发现或得到处理。 有助于组织学习和提高:团队成员有机会在整个生命周期中边做边学, 各显其能。测试员可以早一些开始测试,技术文档编写员可及早开始 编写,其他人也是如此 提高复用性:早期迭代中的设计复审可使构架设计师确定毋庸置疑的 潜在复用部分,并在以后的迭代中开发和完善这些公用代码。 生成性能更强壮的产品:性能上的瓶颈可以尽早发现并处理,而不象 在交付前夕,此时已来不及处理。 ■迭选代流程自身可在进行过程中得到改进和精炼:一次迭代结束时的评 估不伩要从产品和进度的角度来考察项自的情况,而且还要分析组织 和流程本身有什么待改进之处,以便在下次迭代中更好地完成任务
迭代和增量的优点 n 允许变更需求：需求总是会变化，这是事实。 n 逐步集成元素：集成并不只是简单的“一锤定音” 。在迭代式方法中， 集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个 集成部分中，每一部分要集成的元素都比过去少得多。 n 及早降低风险：因为风险一般只有在集成阶段才能发现或得到处理。 n 有助于组织学习和提高：团队成员有机会在整个生命周期中边做边学， 各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始 编写，其他人也是如此。 n 提高复用性：早期迭代中的设计复审可使构架设计师确定毋庸置疑的 潜在复用部分，并在以后的迭代中开发和完善这些公用代码。 n 生成性能更强壮的产品：性能上的瓶颈可以尽早发现并处理，而不象 在交付前夕，此时已来不及处理。 n 迭代流程自身可在进行过程中得到改进和精炼：一次迭代结束时的评 估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织 和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务
初始阶段 Inception 主要目的是将一个好的想法发展为最终产品的一个构想。 本质上,该阶段应回答下面三个问题: 系统向它的每个主要用户提供的基本功能是什么? 该系统的构架看起来是什么样子? 开发该产品的计划如何?开销多大? 该阶段中最关键用例的简化用例模型可以回答第一个问题。 在这个阶段,构架是试验性的,通常只是一个包括主要子 系统的大致轮廓 在这个阶段;要确定最主要的风险及其优先次序,要对细 化阶段进行详细规划,并对整个项目进行粗略估算。 注意,该阶段的目标不是定义所有的需求
初始阶段 Inception n 主要目的是将一个好的想法发展为最终产品的一个构想。 本质上，该阶段应回答下面三个问题： l 系统向它的每个主要用户提供的基本功能是什么？ l 该系统的构架看起来是什么样子？ l 开发该产品的计划如何？开销多大？ n 该阶段中最关键用例的简化用例模型可以回答第一个问题。 n 在这个阶段，构架是试验性的，通常只是一个包括主要子 系统的大致轮廓。 n 在这个阶段，要确定最主要的风险及其优先次序，要对细 化阶段进行详细规划，并对整个项目进行粗略估算。 n 注意，该阶段的目标不是定义所有的需求
初始阶段的目标和任务 建立项目的软件规模和边界条件,包括运作前景、验收标 准以及希望产品中包括和不包括的内容。 ■识别系统的关键用例 对比一些主要场景,展示至少一个备选构架 给出用户提出的非功能性要求描述 评估整个项目的总体成本和进度 评估潜在的风险(源于各种不可预测因素) ■准备项目的支持环境。 ■在阶段后期为细化阶段制定迭代计划
初始阶段的目标和任务 n 建立项目的软件规模和边界条件，包括运作前景、验收标 准以及希望产品中包括和不包括的内容。 n 识别系统的关键用例 n 对比一些主要场景，展示至少一个备选构架 n 给出用户提出的非功能性要求描述 n 评估整个项目的总体成本和进度 n 评估潜在的风险（源于各种不可预测因素） n 准备项目的支持环境。 n 在阶段后期为细化阶段制定迭代计划
初始阶段的工件集 Vision:核心项目需求、关键特性、主要约束的总体构想 Business case:业务用例 Use- case Model:初始的关键用例模型,占10-20%的数量 Risks list Plan a Project-specific templates a Software Development Plan 口| teration plan a Product Acceptance Plan Development Case ■Toos Glossary
初始阶段的工件集 n Vision：核心项目需求、关键特性、主要约束的总体构想 n Business Case：业务用例 n Use-case Model：初始的关键用例模型，占10-20%的数量 n Risks List n Plan ¨ Project-specific templates ¨ Software Development Plan ¨ Iteration Plan ¨ Product Acceptance Plan n Development Case n Tools n Glossary
电子收款机(POs)系统案例 POS机是一个计算机化应用的系统,用于记录销售信息和处理 支付过程,一般超市和零售商店都会用到。该系统的假设条件 如下 〉系统包括终端系统、条码扫描仪等硬件,还有相应的软件系统; >它可能还需要与其他系统存在接口,比如信用卡支付系统、库存 统、记费系统等 >该系统县有一定的容错性能,比如在与库存系统暂时终端连接时, 仍能够进行物品的销售,不至于使系统瘫痪 多样化的终端接口:瘦客户Web终端、PC、触摸屏、无线PDA >能适应不同商店业务销售的功能要求,提供一种灵活性和定制能 男的场能(作为系统开爱的复用需求
电子收款机（POS）系统案例 n POS机是一个计算机化应用的系统，用于记录销售信息和处理 支付过程，一般超市和零售商店都会用到。该系统的假设条件 如下： Ø 系统包括终端系统、条码扫描仪等硬件，还有相应的软件系统； Ø 它可能还需要与其他系统存在接口，比如信用卡支付系统、库存 系统、记费系统等； Ø 该系统具有一定的容错性能，比如在与库存系统暂时终端连接时， 仍能够进行物品的销售，不至于使系统瘫痪； Ø 多样化的终端接口：瘦客户Web终端、PC、触摸屏、无线PDA Ø 能适应不同商店业务销售的功能要求，提供一种灵活性和定制能 力的功能（作为系统开发的复用需求）