细化阶段构造构架基线
当进入细化阶段时，也随之通过了一个主要里程碑，它标志着三项成就：
- 已经阐明了一个初始的构架，这意味着我们指导如何为目标系统建立一个构架，该构造包含了系统中新颖的以及困难的部分。
- 以及识别出了最严重的风险，并且通过对这些风险的研究，对建立系统的可行性充满信息。
- 以及建立了有足够描述信息的初始业务案例以便进入第二阶段，而且以及取得了项目相关人员尤其是投资方的同意。
细化阶段概述
细化阶段的目标是：
- 要捕获大部分尚未开发的需求，并以用况形式表示功能性需求。
- 要建立合理的构架基线，用来指导构造和移交阶段的工作，并进一步用来指导产品将来的升级。
- 要继续监控剩余的关键风险，并要识别出重大风险，以使我们可以估计出风险对业务案例尤其对费用的影响。
- 要向项目计划中加入更详细的描述。
细化阶段初期
制定细化阶段计划
从初始阶段传送过来的西湖额阶段计划可能是没有被彻底完成的。通常，指导细化阶段开始时才能完全指导细化阶段中可利用的资源。随着对资源、开发进度和可用人员的进一步了解，项目经i会修改原理的迭代计划和阶段计划。
组建开发组
并不需要对开发组在初始阶段做的所有工作都做记录。因此，项目经理将根据需要尽可能多第安排该组的成员进入细化阶段。在细化阶段没其他类型的人员也会加入到开发组。项目经理从这些人中会选出一部分进入构造阶段，这部分人有有可能称为设计小组的领导。
改变开发环境
根据初始阶段的开发情况和细化阶段的期望，项目经理继续对开发环境进行调整。
设立评价准则
迭代或细化阶段索要达到的特定准则对于不同的项目在总体上各不相同，但可以根据该阶段的目标来考虑
扩展需求
评价准则是：
- 是否移交识别出设计构架基线、识别重大风险移交支持业务案例和标书所需要的需求、参与者和用况。
- 为了达到本阶段的目标，是否已经对这些目标进行了详细而充分的描述？
建立基线的构架
评价准则是：
- 可执行的构架基线是否不仅满足了正式捕获的那些需求，而且还满足了项目相关人员观察工作基线后所体会到的需求？
- 构架基线看上去是否足够健壮，使之可以承受构造阶段以及后续版本可能需要的额外特征的考验？
缓解重大风险
评价准则是：
- 关键风险是否已经得到了适当的缓解？
- 是否已经识别出所有的重大风险？
- 对重大风险的研究是否已经到达了可生成标书的程度？
- 是否可在构造阶段正常地排除仍保留在风险清单上的风险？
判断业务案例的价值
评价准则是：
- 是否对项目进行了充分的定义并确定了标书的费用、开发进度和质量？
- 业务案例是否能提供投资回报或达到业务所规定的投资障碍率。
- 言而言之，是否为已定价的合同做好了准备？
原型的细化迭代工作流
我们再次部分并行地开展四组活动。第一组是核心工作流；第二组是制定迭代计划；第三组是评估；第四组是进一步准备开发环境。
捕获并细化绝大多数需求
识别约80%的用况。我们可能像是描述用况群的40~80%。在详细描述的用况群中，我们大约选出其中的一般通过分析进行仔细的检查。我可能发i西安，需要考虑的金是占一半用况中的部分场景。
开发构架基线
构架设计师对用况进行优先级排序，并进行构架层次上的菲尼、设计和实现工作。而另一些工作人员则进行分析和设计工作。测试工程师则集中精力建立测试环境，对构件进行测试，并对狗构件意义的用况实现的整个基线进行测试。
开发组较小的迭代
在细化阶段，开发组的规模仍然很小，但需要进行迭代并尝试不同的解决方案。迭代会不停的进行，指导构架达到一个稳定的水平，即构架可以说明系统是可接受的，并且达到很少发现变化的程度。
执行五个核心工作流-从捕获需求到测试
捕获需求
确定用况和参与者
系统分析人员识别出在初始阶段没有发现的用况和参与者。为了达到本阶段的目标，我们需要了解80%的用况，但并步需要详细描述那么多用况。我们可能识别处理几乎全部的用况，但只需要详细描述其中的一部分，且只分析经过详细描述用况中的一部分。
整理索要的了解，是指什么是对构架有重要意义的，并且确定没有遗漏任何可能影响构架和标书的用况。
构造用户界面原型
区分用况的优先级
在初始阶段准备好的局部用况模型的基础上，我们将以按照两条线进行开发：添加更多的用况和按构架基线开展工作。
首先，要花一定的实际来寻找更多的用况，接着把注意力转移到构架上。
详细描述一个用况
用况描述人员要详细描述那些彻底理解需求所必须的用况已经建立构架基线所必须的用况。
构造用况模型
系统分析人员审查自己所做的工作，并寻找其中的相似点、可简化点已经改善用况模型结构的机会。
分析
我们在初始阶段提出了分析模型的一个草案。现在，我们将在次基础之上进行开发，但我们会发现不得不废弃其中相当大的一部分。
构架分析
初始阶段所进行的构架分析只达到确认构架可行性的程度，通常并不是十分深入的。
分析用况
分析一个类
分析一个包
设计
在本阶段，我们通常设计和是西安不朝贡10%的用况群。
构架设计
设计一个用况
设计一个类
设计一个子系统
实现
该工作流从考察对构架有重要意义的设计元素开始，实现和测试对构架有重要意义的构架，其结构就是构架基线。构架基线常常是由少于10%的用况群实现的。
构架实现
实现一个类和实现一个子系统
集成系统
测试
测试的终点是要确定在所有水平和所有层次上的子系统及其接口时可运行的。
从较低的构架曾开始测试，这表示要测试对象的发你不、存储、检索和并非以及系统较低层的其他机制。测试不仅包括对功能的测试，还包括对性的测试。
制定测试计划
执行集成测试
执行系统测试
产生业务案例
缓解风险和构建构架基线的根本理由是让项目进行到开发组可进入构造阶段的程度。此时，开发组由充分的信息能在业务范围内构造产品。本质上，有两种业务限制，其一是一个给定质量下的进度、人力和费用的估计，其二是投资回报表示目标系统在经济上将是成功的。
准备业务标书
开发组期望在类似于业务关系的基础上开展构造阶段的工作。
更新投资回报
业务案例从本质上讲就是：软件产品从使用或者销售中所获得收益是否能抵消开发所投入的费用？产品能否及时地投入十尝从而获得利润？
软件组织现在能以业务标书的形式估计构造和移交阶段的费用，标书体现了业务案例的一方面情况；但是另一方面，并步村子啊计算机软件将能获得多少收益的简洁公式。
对上市软件而言，售价、消失了、消声器都是值得项目精力考虑和判断的问题。对内部使用的软件而言，应要求使用该润洁的部分估计所期望的节省效果。估计潜在收益的误差通常很大，但是这种估计至少可以帮助权衡得失。
评估细化阶段的迭代
每次迭代结束时，都应该根据这次迭代开始前所制定的迭代计划进行评估。评估小组评审每次迭代的结构，验证基线石佛真正代表构架起到了完成原定目标和缓解风险的作用。
细化阶段结束时，评估小组将使项目相关人员详细，细化阶段移交缓解了重大风险，移交建立了一个稳定的构架基线，系统能够移交项目计划和构造阶段的标书进行构建。
制定构造阶段计划
细化阶段快结束时，项目精力开始详细计划构造阶段的第一次迭代，并用非常概括性的术语u几下剩余的部分工作。
关键的可交付内容
可交付的内容有以下八项：
- 描述系统语境的一个相当完善的业务模型。
- 所有模型的新版本。
- 可执行的构建基线
- 构建说
- 更新过的风险清单
- 构造阶段和移交阶段的项目计划
- 初步的用户手册。
- 完整的业务案例。