构造阶段形成初步可运行能力
本阶段的主要目的是生成软件产品的一个初步可运行版本。该产品达到可应用的质量，且满足续期。构造阶段应在业务计划的限制范围内开展构造工作。
构造阶段概述
开发组在构造极端的工作是从一个可执行的构建基线着手，通过一系列的迭代和增量过程，开发出一个准备在用户缓解中初步运行的软件产品
当工程从西湖按阶段过度到构造阶段时，工作终点会有所变化。初始和细化阶段可比喻成研究，而构造阶段则类似于开发。充电从手机构建项目所需要的基本知识，转向在给定的费用、工作流和进度范围内实际构造系统或产品。
在构造阶段中，项目精力、构架设计师和高曾开发人员应该确保：对用况进行优先级排序；对用况加以分组并成成构造和迭代；按规定的顺序开发并避免返工。
通过持续第更新来保持风险清单的实时性，这样才能反映项目当前的实际风险，目标时在该阶段结束时，所有的风险都得到缓解。
构造阶段初期
细化阶段结束时，项目精力制定构造阶段计划。当他或她得到投资方的授权后，可以根据实现情况修订几乎。特邀注意下面两种经常可能发生的情况：
- 细化阶段和构造阶段可能出现的时间空隙。
- 资金和进度比项目在西湖按阶段所计划的要少。
本阶段人员安排
构造阶段的工作时在构架上展开的。构架设计师在细化阶段识别的服务子系统并不完善，他们金实现了核心用况及其核心场景。
带有子系统和接口陈述的构架基线，时项目精力划分工作的依据。每一个子系统会由一位担当构建工程师职责的开发人员来复杂。
设立评价准则
由迭代和构造姐u但产生的特定的评价准则对每个项目都是唯一的。
每个构造或迭代都实现一组共可，因此，对这一组用况的评价就基于与其相关的功能性或非功能性需求。这些与用况相关的评价准则也使得开发人员在完成特定的构造或迭代后能更清楚地了解自己的工作情况。
此外，制定构造阶段所需要的评价准则还需要准备别的一些补充材料，例如：
- 用户资料，为支持最终用户，在构造阶段需要准备文字资料的第一个剪辑。评价准则时：这些文字资料能否为用户提供充分的支持？
- 教程产品，为支持最终用户，在本阶段还需要准备教程的第一个剪辑。评价准则是：在移交阶段，他们能否为用户提供充分的支持。
总体上来讲，对于构造阶段，评价的准则是：初步可运行能力是否足够成熟与稳定，能否达到把beta版软件交给用户团体时不会让软件组织或者用户团体遭受无法接受的风险？
原型的构造迭代工作流
我们再次部分并行的开展四组活动。第一部分时五个核心工作流；第二部分时迭代计划；第三部分时业务案例，第四部分时评估。
制定五个核心工作流-从捕获需求到测试
捕获需求
在构造阶段，要千方百计地实现一个初步可运行的胸痛，因此，不得不全面地展开需求捕获工作。
- 确定参与者和用况，通常只有少数参与者和用况留到构造阶段来定义。如果必要，由系统分析人员更新用况模型中的参与者和用况。
- 构造用户界面原型，一般来讲，不在初始解u但和西湖按阶段构造用户界面原型，出发需要用于显示的目的或出现了新型界面。而现在，用户界面就非要设计不可了。
- 区分用况的优先级，细化阶段曾对开发构建基线所需的用况进行了优先级排序，在本阶段定义用况时，统一要按顺序把他们基金优先级清单中去。
- 详细描述一个用况，按剩余用况和用况场景的重要性，由用况描述人员完成细化工作。
- 构造用况模型，系统分析人员也许希望改善用况模型的结构，但系统构造在本阶段已较为稳定，任何改动都要首先靠还没有处理的额用况。
分析
在细化阶段，仅关注那些对整体构建和业务标书直观重要的用况。在构造阶段，完成分析模型。
- 构架分析，到细化阶段结束时，构架设计师已准备好分析模型的构架视图，在构造阶段很少进行构架分析活动。
- 分析一个用况，在细化姐u但，构架设计师仅使用那些对构架有重要意义的、并应用与分析模型的构架视图的用况。在构造阶段的每次迭代中，我们要用该迭代所包含的用况来扩展分析模型。
- 分析一个类，构架工程师继续他们在细化阶段开始的工作。
- 分析一个包，构架设计师在细化阶段是闭包，并在构造阶段讲其提炼到新用况所需的程序。
设计
在本阶段，通常要设计并实现余下的、没有被用于开发构架基线的90%的用况
实现
该工作流首先从设计模型出发，实现并制定所有构件的单元测试。
- 构架实现，到此时，构架牢固地建立起来。构架设计师的任务知识在必要时更新构架。
- 实现一个类和实现一个子系统，构架工程对实现模型中的类和子系统加以实现。
- 执行单元测试，构架工程师复杂对其所开发的构架执行单元测试。
- 集成系统，系统集成人员要制定一个集成计划，勾画出构造的顺序。该计划阐明构造要实现俺的用况或者用况中的场景。
测试
测试工程师的工作，师发现可有效测试的内容、设计测试环境、测试规程并对其进行测试。
- 制定测试计划，测试工程师选择每个构造即系统本身的测试目标。
- 设计测试，测试工程找出如何测试构造集中的需求的方法，已验证可测试的需求的正确性。
- 执行集成测试，集成测试人员按照测试规程运行测试用例，构造通过测试后，系统集成人员再增加新的构造，到可测试时，测试人员再进行测试，如此反馈。
- 执行系统测试，当持续的构造过程到达一次迭代的末期时，就形成了一个局部性的系统，并进入到系统测试人员的权限内。
- 评价测试，当进行集成和系统测试时，测试工程师移交测试计划中的原定目标，再每次构造完成时，评审测试结构。
控制业务案例
在细化阶段结束时准备好业务标书的目的之一时为项目精力和项目相关人员i提供实施构造阶段所需的指南。
在构造姐u但，随着项目精力对产品费用和实际性能拥有更深入的了解，她会觉得有必要更新业务案例并于项目相关人员探讨新的情况。
评估构造阶段的迭代
基于测试结构以及其他评价准则的评审，项目精力和评估小组着手实施以下事项：
- 审查迭代中的工作是否有于原计划相矛盾的内容
- 计划在后面的那一次爹地啊中实现未完成的工作。
- 确定构造是否完成以决定是否进入下一次迭代。
- 封信风险清单
- 制定下一次迭代的计划。
- 为下一次迭代之后的迭代更新计划。
- 在本阶段的最后一次迭代结束时，确定产品是否已通过系统测试并且已大豆初步可运行能力
- 授权进入移交测试
- 更新项目计划。
制定移交阶段计划
项目组，不能期望想一位各界u但那样，预先为移交阶段制定详细的计划。
关键的可交付内容
可交付的内容包括：
- 移交姐u但的项目计划。
- 可执行软件本身-初步可运行版本，它时构造阶段的最后一个构造。
- 包括系统模型在内的所有制品
- 维护并最低限度地更改构架描述
- 指导β版用户的足够详细的初步的用户手册。
- 反映本阶段后期清晰的业务案例。
目的时希望被标为完善的可交付内容确实时完善的。