5. 生命周期工件

    开发过程不是文档驱动的：它的工件中必须一直包括软件产品自身。文档应该十分精简，数目不能太多，应只保留那些确实从管理或技术的角度有真正价值的文档。 Rational 建议保留以下典型的文档集。

    5.1管理工件
    管理工件不是产品，而是用来驱动或监控项目进展、估计项目风险、调整项目资源，以及使客户或投资者对项目保持一定的"可见性" 的。

    . 一份机构策略文档，是机构开发过程的明文规定。 它包含一个此类项目的实例。
    . 一份远景文档, 描述系统级需求，质量要求和优先级。
    . 一份业务案例文档, 描述财务环境、合同，以及项目的投资回报等等。
    . 一份开发计划文档, 包括总体的迭代计划和当前及近期迭代的详细规划。
    . 一份评估标准文档，包括需求、验收标准及其他特定的技术目标，它们由各个阶段演进的主要"里程碑"组成。包含迭代的目标和验收水平。
    . 每次发布的版本描述文档。
    . 部署文档, 包含对交付、培训、安装、销售、制造和交割相关的有用信息。
    . 状态评估文档: 项目状态的阶段性"快照"， 具有进展、人力、开销、结果、关键风险、活动等的度量标准。

    5.2技术工件

    它们或者是交付的产品，可执行的软件及手册，或者是一些用于制造产品的蓝图，这些产品包括软件模型、源代码和其他有助于理解和演进产品的工程信息。

    . 用户手册, 在生命周期早期开发。
    . 软件文档, 最好以源代码自建文档和模型的形式，其中模型是用合适的CASE工具捕获并维护的这些模型包括用例、类图和过程图等。
    . 一个软件构架文档, 描述软件的整体构架，及它的主要组成元素的分解说明： 类的分组、类、过程、子系统、关键接口的定义和关键设计决策的依据。

    本文第3部分中列举的入口准则和出口准则可以映射到这11类文档之中。

    上面介绍的这套文档可以依照具体项目的类型进行扩充和删减，一些文档可以合并。 文档不必一定是纸张形式---也可以是电子表格、文本文件、数据库、源代码的注释、超文本文档等等---但相应的信息资源必须被清楚地识别，易于访问，也要保存一些历史记录。

    5.3需求

    Rational 软件开发过程也不是需求驱动的。 在产品演进的周期中，需求表现为不同的形式：

    . 业务案例给出了主要约束，多是些可用的资源。
    . 远景文档从用户角度仅描述了系统的关键需求，它在开发过程中将缓慢演进。
    . 更详细的需求在第二阶段（细化阶段）以用例和场景的形式进行阐明，并在第三阶段（构建阶段）随着对产品和用户需求了解的加深进一步精化。这些更详细的需求记录在评估标准文档中，它们驱动了构建阶段和移交阶段迭代内容的定义， 并在迭代计划中引用。

    6. Rational过程的例子
    
    按照2.4节中所述的区别，Rational 过程采用不同的形式。 这里有两个极端的例子。

    6.1大型契约性软件开发的Rational过程
   
    对这个软件开发项目，Rational 过程分为3个阶段建立招标, 对应3个不同类型的合同。

    一个研究与设计阶段, 包含了生命周期的起始阶段和细化阶段, 通常以风险分担方式投标，举例来说，成本加奖金合同（ cost plus award fee contract ，CPAF）。

    . 一个生产阶段，包含了生命周期的构建和移交阶段, 通常作为一个公司、固定的价格合同（a firm, fixed price contract ,FFP）来投标。
    . 一个维护阶段，对应生命周期的演进阶段，通常作来工作量水平合同（ a level of effort contract ，LOE）来投标。
    . 因为用户需要更高的可视性来评估项目，还因为项目涉及大量人员和组织，开发过程应更加正规化，要比小型、内部的项目更加重视书面工件。第5部分列出的11类文档都以某种形式或名称存在。