迭代增量的软件生命周期模型描述

赛柏科技组织研发管理体系迭代增量式软件开发生命周期模型描述版本 0.1 组织研发管理体系 版本: 0.1迭代增量式软件开发生命周期模型描述 日期: 2009-4-6变更记录日期版本描述作者2009-4-60.l创建迭代增量式软件开发生命周期模型描述汪浩目 录1.前言11.1目的11.2适用范围12.模型总述22.1概述22.2迭代增量式软件开发生命周期模型的模型要素组织42.3生命周期模型的二维组织框架73.角色与职责93.1分析员角色集合93.2开发人员角色集合113.3测试人员角色集合143.4管理人员角色集合153.5其他角色集合184.阶段204.1阶段 - 先启204.2阶段 - 精化204.3阶段 构建224.4阶段 产品化（移交）225.工件15.1业务建模工件集15.2需求工件集95.3分析设计工件集工件集195.4实施工件集275.5测试工件集315.6部署工件集365.7项目管理工件集395.8配置与变更管理工件集455.9环境工件集476.工作流程16.1迭代的工作流16.2核心工作流描述26.2.1核心工作流 业务建模26.2.2核心工作流 需求56.2.3核心工作流 分析设计86.2.4核心工作流 实施116.2.5核心工作流 测试146.2.6核心工作流 部署176.2.7核心工作流 配置与变更管理206.2.8核心工作流 项目管理236.2.9核心工作流 环境277.过程检查点327.1主要里程碑327.1.1生命周期目标里程碑337.1.2生命周期构架里程碑347.1.3最初操作性能里程碑367.1.4产品发布里程碑377.2次要里程碑387.3定期状态评估点398.裁减指南19.参考文献110.评审记录1受控赛柏科技, 2000iv迭代增量式软件开发生命周期模型描述1. 前言1.1 目的该文档为组织定义的迭代增量式软件开发生命周期描述，用于作为组织软件开发流程指导和详细流程的开发基础。1.2 适用范围适用于组织所有的开发类项目、升级类项目。本文档提供了迭代增量式软件开发生命周期模型定义描述。开发类项目是指公司新承接的，由客户方提出的，有明确需求的项目，或由公司自主立项的新项目。该类项目一般有比较完整的软件生命周期，也可能根据项目的具体情况将其中几个阶段合并或拆分。升级类项目是指公司对原有开发完毕项目进行的后期开发项目，后期开发的主要内容可能包括前期项目的缺陷修复、功能增强、新功能等等。2. 模型总述2.1 概述迭代增量式开发主要是针对瀑布式模型存在的缺陷而提出的。在一般情况下，初始设计就其关键需求而言很有可能是有缺陷的。到后期才发现设计缺陷会导致非常严重的费用超支，在某些情况下甚至会导致项目被取消。瀑布模型很难规避这样的风险，瀑布模型中风险的变迁可表示如下图。图 1 瀑布模型中的风险变迁示意图任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么项目计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。然而，不管开发团队经验如何，都绝不可能预知所有的风险。而迭代增量式开发将整个项目周期分为很多个迭代，采用一种较灵活（并且风险更小）的方法多次执行各个开发工作流程，从而更好地理解需求、设计出强壮的构架、组建好开发组织并最终交付一系列渐趋完善的实施成果。这被称为迭代增量式生命周期。每次按顺序完成这一系列工作流程就叫做一次迭代，参见下图。图 2 迭代示意随着迭代次数的增加，递增式的完成功能的增加。因此，这种开发模式也往往称为迭代增量式开发，示意如下。图 3 迭代增量式开发示意在迭代增量式生命周期中，需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。迭代增量式模型中风险的变迁与瀑布相比则可用下图表示。图 4 迭代增量式模型中风险变迁与瀑布模型情况相比示意概括的说，迭代式增量式开发的优点： 允许变更需求。给项目带来麻烦的常常主要是需求变化和需求“蠕变”，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。 逐步集成元素 - 集成并不只是简单的“一锤定音”。在迭代式方法中，集成可以说是连续不断的。 及早降低风险，因为风险一般只有在集成阶段才能发现或得到处理。 有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学。 提高复用性，因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。 生成性能更强壮的产品，因为在多次迭代中项目总是不断地纠正错误。 迭代流程自身可在进行过程中得到改进和精炼。 容许产品进行战术改变；例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。2.2 迭代增量式软件开发生命周期模型的模型要素组织下面为采用UML类图组织的迭代增量式软件开发生命周期模型要素关系图。图 5 迭代增量式软件开发生命周期模型要素关系图其中主要生命周期模型元素的解释参见下表。表 1 迭代增量式生命周期模型主要元素一览表模型要素解释角色角色是流程中最重要的概念之一。角色定义了在软件工程组织的环境中，个人或协同工作的多人小组的行为和职责。角色代表项目中个人承担的任务，并定义其如何完成工作。角色是抽象的职责定义，它定义的是所执行的一组活动和所拥有的一组工件。活动活动是参与项目的角色为提供符合要求的结果而进行的工作。工件工件分为输入工件和输出工件。工件是流程的工作产品：角色使用工件执行活动，并在执行活动的过程中生成工件。工件是单个角色的职责，它体现的是这样一种思想：流程中的每条信息都必须是一个具体的人的职责。即使一个人可能“拥有”某个工件，但其他人也可以使用该工件，如果授予权限，或许他们还可以更新这个工件。阶段从管理的观点来说，任何软件生命周期随着时间都可分为多个依次进行的阶段，每个阶段的结束都有一个主要里程碑；实质上，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估（活动：生命周期里程碑复审），以确定是否实现了此阶段的目标。里程碑里程碑标志着本阶段的结束和下一阶段的开始。每个里程碑都侧重于一个特定的可交付工件；每个里程碑都明确定义了进入下一阶段的转移点。每个里程碑都代表了一个项目必须清除的重要障碍；在每个里程碑处，项目都要面对继续或停止的决定。工作流程工作流程显示生成特定的工件集可能要经历的所有活动。在随后工作流程章节采用活动图形式对模型中各种工作流程进行描述。迭代迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。输入准则对于活动来说，输入准则主要判断输入工件是否准备就绪，是否所依赖的活动已经结束或开始；相应资源是否就绪等；对于阶段和迭代来说，输入准则主要判断上一阶段的主要里程碑或上一迭代的迭代里程碑是否满足，参见上面里程碑定义。输出准则对于活动来说，输出准则主要判断输出工件是否按质完成；对于阶段和迭代来说，输入准则主要判断阶段主要里程碑或迭代里程碑是否得以满足。在随后的模型描述中，将借鉴RUP图形表示方法，采用下图中图元描述角色、活动、工件之间的关系。图 6 迭代增量式生命周期模型核心概念的图元表示2.3 生命周期模型的二维组织框架参照RUP和USDP模型，此处我们根据时间和工作流可将软件开发生命周期组织为下图所视的二维空间框架。图 7 迭代增量式开发生命周期模型框架示意如图所示，时间维从组织管理的角度描述整个软件开发生命周期，是迭代增量式软件开发生命周期模型的动态组成部分。它可进一步描述为周期、阶段、迭代。核心工作流从技术角度描述迭代增量式软件开发生命周期模型的静态组成部分，它可进一步描述为活动、工作流、工件、角色。图中的阴影部分描述了不同的工作流，在不同的时间段内工作量的不同。值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是大小不同而已。这与瀑布模型有明显的不同。迭代增量式软件开发生命周期模型常采用用例的概念管理需求，把要开发的系统根据各功能使用的情况划分多个用例，并采用迭代的思想把系统的风险分布在四个阶段，风险越大的迭代越要放在靠前的阶段做，使软件产品的风险不断降低；而不是像传统瀑布模型那样越往开发的后期问题越多。从管理的观点来说，软件生命周期随着时间分为四个依次进行的阶段，每个阶段的结束都有一个主要里程碑。在每个阶段结束时进行评估，以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。3. 角色与职责参照RUP和USDP，迭代增量式软件开发生命周期模型将模型中所有角色组织成五个角色集合：分析员角色集合、开发人员角色集合、测试人员角色集合、管理人员角色集合和其他角色集合。3.1 分析员角色集合表 2 分析员角色集合相关角色描述角色名称职责参与活动与涉及工件业务流程分析员业务流程分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何进行交互。业务设计员业务设计员通过描述一个或几个业务用例的工作流程来详细说明组织中某一部分的规约。他通过描述一个或几个业务用例的工作流程来详细说明组织中某一部分的规约。他指定实现业务用例所需的业务角色及业务实体，并且将业务用例的行为分配给这些业务角色及业务实体。业务设计员定义一个或几个业务角色和业务实体的责任、操作、属性和关系。业务模型复审员业务模型复审员参与对业务用例模型和业务对象模型的正式复审。需求复审员需求复审员负责计划并执行对用例模型的正式复审。系统分析员系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。用例阐释者用例阐释者通过描述一个或几个用例的需求状况以及其他支持软件的需求，详细说明系统功能某一部分的规约。用例阐释者还可负责用例包，并保持用例包的完整性。建议负责用例包的用例阐释者同时负责用例包所包含的用例和主角。用户界面设计员用户界面设计员通过以下方法领导和协调用户界面的原型设计和正式设计： 分析对用户界面的需求，包括可用性需求； 构建用户界面原型；邀请用户界面的其他涉众（如最终用户）参与可用性复审和使用测试会议；对用户界面的最终实施方案（由设计员和实施员等其他开发人员创建）进行复审并提供相应的反馈。3.2 开发人员角色集合表 3 分析员角色集合相关角色描述角色名称职责参与活动与涉及工件构架设计师构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。构架复审员一般而言，构架复审员负责计划并执行对软件构架的正式复审。封装体设计员封装体设计员的主要工作是根据并行需求确保系统能够及时地对事件作出响应。代码复审员代码复审员负责确保源代码的质量，并且计划和执行源代码复审。在复审活动中，代码复审员还负责有关返工的任何反馈意见。数据库设计员数据库设计员定义表、索引、视图、约束条件、触发器、存储过程、表空间或存储参数，以及其他在存储、检索和删除永久性对象时所需的数据库专用结构。相关信息记录在工件：数据模型中。设计复审员设计复审员计划并进行工件：设计模型的正式复审。设计员设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。此外，设计员可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。实施员实施员负责按照项目所采用的标准来进行构件开发与测试，以便将构件集成到更大的子系统中。如果必须创建驱动程序或桩模块等测试构件来支持测试，那么实施员还要负责开发和测试这些测试构件及相应的子系统。集成员实施员将经测试的构件交付到集成工作区，由集成员在集成工作区将构件组合起来，生成一个工作版本。集成员还负责制定集成计划。集成在子系统和系统级别进行，每次集成均有独立的集成工作区。正如经测试的构件从实施员的专用开发工作区交付到子系统集成工作区一样，已集成的实施子系统也从子系统集成工作区交付到系统集成工作区。3.3 测试人员角色集合表 4 分析员角色集合相关角色描述角色名称职责参与活动与涉及工件测试设计员测试设计员是测试中的主要角色。该角色负责对测试进行计划、设计、实施和评估，包括： 生成测试计划和测试模型 执行测试过程 评估测试范围和测试结果，以及测试的有效性 生成测试评估摘要测试员测试员负责执行测试，其职责包括： 设置和执行测试 评估测试执行过程并修改错误3.4 管理人员角色集合表 5 分析员角色集合相关角色描述角色名称职责参与活动与涉及工件项目经理项目经理负责分配资源，确定优先级，协调与客户和用户之间的沟通。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。流程工程师流程工程师对软件开发流程本身负责。其职责包括在项目开始前配置流程，并在开发工作过程中不断改进流程。变更控制经理变更控制经理这一角色负责对变更控制过程进行监督。此角色通常由配置（或变更）控制委员会 (CCB) 来担任，该委员会应该由有关各方（包括客户、开发人员和用户）的代表组成。在小型项目中，项目经理或软件构架设计师一人即可承担此角色。配置经理配置经理负责为产品开发团队提供全面的配置管理 (CM) 基础设施和环境。CM 的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。配置经理还必须确保 CM 环境有利于进行产品复审、更改和缺陷跟踪等活动。配置经理还负责撰写 CM 计划并汇报基于“变更请求”的进度统计信息。部署经理部署经理负责制定向用户群体发布产品的计划，并将其纳入布署计划中。项目复审员（QA）项目复审员负责在项目生命周期中的主要复审点处评估项目计划工件和项目评估工件。在这些复审点发生的是非常重要的复审事件，因为在它们所标志的时间点处，如果计划不够充分或者进展无法令人满意，项目很可能会就此取消。系统管理员系统管理员负责维护支持开发环境、硬件和软件、系统管理、备份等。3.5 其他角色集合表 6 分析员角色集合相关角色描述角色名称职责参与活动与涉及工件任意角色如果具有访问权限，在模型中确定的任何角色均可以“检入”和“检出”任何与产品相关的工件，以便在配置控制系统中进行维护。此外，任意角色都可以提交变更请求，并且对它们所拥有的变更请求进行更新。课程开发员课程开发员开发用户用来学习产品使用的培训材料。其中包括制作幻灯片、学员说明、示例、教程等，以增进学员对产品的了解。涉众涉众是所有会受到项目结果重大影响的人。技术文档编写员技术文档编写员负责制作最终用户支持材料，例如用户指南、帮助文本、发布说明等。工具专家工具专家负责项目中的支持工具。其中包括选择和购买工具。工具专家还要配置和设置工具，并核实工具是否可以使用。4. 阶段从管理的观点来说，迭代增量式软件开发生命周期随着时间分为四个依次进行的阶段，每个阶段的结束都有一个主要里程碑；实质上，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估，以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。4.1 阶段 - 先启表 7 阶段 先启阶段名称先启目标先启阶段的基本目标是实现项目的生命周期目标中所有涉众之间的并行。先启阶段主要对新的开发工作具有重大意义，新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。对于重点是扩展现有系统的项目来说，先启阶段较短，但重点仍然是确保项目值得进行而且可以进行输入立项申请核心活动 明确地说明项目规模。这涉及了解环境以及最重要的需求和约束，以便于可以得出最终产品的验收标准。 计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备选方案。 综合考虑备选构架，评估设计和自制/外购/复用方面的折衷，从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。先启阶段的原型设计工作应该限制在确信解决方案可行就可以了 - 该解决方案在精化和构建阶段实现。 * 准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。输出参见7.1相应里程碑信息。里程碑生命周期目标里程碑，参见7.1。4.2 阶段 - 精化表 8 阶段 精化阶段名称精化目标精化阶段的目标是建立系统构架的基线，以便为构建阶段的主要设计和实施工作提供一个稳定的基础。构架是基于对大多数重要需求（对系统构架有很大影响的需求）的考虑和风险评估发展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。精化阶段的主要目标包括： 确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。对大多数项目来说，通过此里程碑也就相当于从简单快速的低风险运作转移到高成本、高风险的运作，并且在组织结构方面面临许多不利因素。 处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架，它是通过处理构架方面重要的场景得到的，这些场景通常可以显示项目的最大技术风险 制作产品质量构件的演进式原型，也可能同时制作一个或多个可放弃的探索性原型，以减小特定风险 证明已建立基线的构架将在适当时间、以合理的成本支持系统需求 建立支持环境输入项目计划本阶段迭代计划核心活动 快速确定构架、确认构架并为构架建立基线。 根据此阶段获得的新信息改进前景，对推动构架和计划决策的最关键用例建立可靠的了解。 为构建阶段创建详细的迭代计划并为其建立基线。 改进开发案例，定位开发环境，包括流程和支持构建团队所需的工具和自动化支持。 改进构架并选择构件。评估潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。输出参见7.1相应里程碑信息。里程碑生命周期框架里程碑，参见7.1。4.3 阶段 构建表 9 阶段 构建阶段名称构建目标构建阶段的目标是阐明剩余的需求，并基于已建立基线的构架完成系统开发。构建阶段从某种意义上来说是一个制造过程，在此过程中，重点在于管理资源和控制操作，以便优化成本、进度和质量。从这种意义上说，从先启和精化阶段到构建和产品化阶段，管理上的思维定势经历了从知识产权开发到可部署产品开发的转变。构建阶段的主要目标包括： 通过优化资源和避免不必要的报废和返工，使开发成本降到最低 快速达到足够好的质量 快速完成有用的版本（Alpha 版、Beta 版和其他测试发布版） 完成所有所需功能的分析、开发和测试。 迭代式、递增式地开发随时可以发布到用户群的完整产品。这意味着描述剩余的用例和其他需求，充实设计，完成实施，并测试软件。 确定软件、场地和用户是否已经为部署应用程序作好准备。 开发团队的工作实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现自然的并行（资源允许）。这种并 行性可较大幅度地加速开发活动；但同时也增加了资源管理和工作流程同步的复杂程度。如果要实现任何重要的并行，强壮的构架至关重要。输入演化阶段的需求构架设计概要设计核心活动 资源管理，控制和流程优化 完成构件开发并根据已定义的评估标准进行测试 根据前景的验收标准对产品发布版进行评估输出参见7.1相应里程碑信息。里程碑最初操作性能里程碑，参见7.1。4.4 阶段 产品化（移交）表 10 阶段 产品化阶段名称产品化（移交）目标产品化阶段的重点是确保最终用户可以使用软件。产品化阶段的主要目标包括： 进行 Beta 测试，按用户的期望确认新系统 Beta 测试和相对于正在替换的遗留系统的并行操作 转换操作数据库 培训用户和维护人员 市场营销、进行分发和向销售人员进行新产品介绍 与部署相关的工程，例如接入、商业包装和生产、销售介绍、现场人员培训 调整活动，如进行调试、性能或可用性的增强 根据产品的完整前景和验收标准，对部署基线进行的评估 实现用户的自我支持能力 在涉众之间达成共识，即部署基线已完成 在涉众之间达成共识，即部署基线与前景的评估标准一致输入开发结束里程碑报告质量审计报告配置审计报告测试总结报告配置审计通过的软件产品，和程序包核心活动 执行部署计划 对最终用户支持材料定稿 在开发现场测试可交付产品 制作产品发布版 获得用户反馈 基于反馈调整产品 使最终用户可以使用产品输出参见7.1相应里程碑信息。里程碑生命周期目标里程碑，参见7.1。受控赛柏科技, 200915. 工件工件是项目期间生成并使用的最终或中间产物。工件用于获取和传达项目信息。工件可以是以下的任何一种： 文档，如商业理由或软件构架文档 模型，如用例模型或设计模型 模型元素，即模型中的元素，如类或子系统模型与模型元素都有相关联的报告。报告从工具中提取有关模型和模型元素的信息。报告表示一个或一组工件。大多数工件有指南，用于更详细地说明工件。为使整个软件系统的开发易于管理，工件根据核心工作流程（参见章节6）组织成各个工件集。有些工件在若干核心工作流程中都要用到（例如： 风险列表、软件构架文档和迭代计划）， 这些工件属于最初生成它们的核心工作流程集。5.1 业务建模工件集业务建模集介绍了获取并提供系统业务环境的工件。业务模型工件充当系统需求的输入，还作为系统需求的参考。表 11 工件 业务建模工件集工件名称描述目的职责业务词汇表业务词汇表定义在项目的业务建模部分所使用的重要术语。项目有一个业务词汇表。此文档对于许多开发人员来说非常重要，尤其是当他们需要了解和使用该项目的特定术语时显得更为重要。业务流程分析员负责业务词汇表的完整性，确保： 业务词汇表及时确定。 保持业务词汇表与词汇表一致，并且不重叠。 始终与开发结果保持一致。目标组织评估目标组织评估说明了要在其中部署系统的组织的当前状态。需要说明以下几点：当前各流程、工具、人员才能、人员态度、客户、竞争对手、技术趋势、问题及待改进之处。用作为特定项目配置业务建模工作流程的基础业务流程分析员负责目标组织评估业务规则业务规则是必须遵守的政策或条件的声明本文档定义应用于业务的业务规则。 如果需要，这些业务规则可分成若干个主题组业务流程分析员负责业务规则文档的完整性，确保： 及时生成业务规则文档。 始终与开发结果保持一致。业务前景业务前景确定了业务建模工作针对的目标和对象。业务前景文档记录了业务建模工作相当高层的目标。它为项目认可流程提供输入信息，因此它与商业理由和软件工程工作的前景文档密切相关。它传达了与项目有关的最根本的“什么和为什么”的问题，将来确认所有决策时都应以此为标准。经理、出资方、业务建模的角色和一般的开发人员将阅读业务前景文档。业务流程分析员负责业务前景文档的完整性，并确保： 业务前景文档已经更新和分发。 来自所有相关涉众的输入都予以考虑。业务用例模型业务用例模型是说明业务预期功能的模型。作为一个核心输入模型，业务用例模型用于确定组织的各个角色和可交付工件。下列人员使用业务用例模型： 客户，使用业务用例模型来检验您对业务环境的了解程度，以便批准继续进行系统开发。 构架设计师，使用业务用例模型从构架上确定应实现自动化的重要行为。 系统分析员，使用业务用例模型更好地了解系统的环境。 经理，使用业务用例模型计划并跟踪业务建模工作及随后的软件开发。 组织内的非项目人员、经理和指导委员会使用业务用例模型了解已做的工作。业务流程分析员负责业务用例模型的完整性，确保： 就整体而言，模型具有正确性、一致性和可读性。 业务用例模型所涵盖的业务足以为构建系统提供良好的基础。业务构架业务构架文档通过采用许多不同的构架视图来描述业务的不同方面，对业务进行了全面概述。业务构架文档综合概述了业务的结构及目的。作为业务流程分析员和其他项目组成员之间的沟通媒介，它包含对业务的主要功能和机制的定义。业务流程分析员负责编制业务构架文档，该文档记录业务的多个构架视图中最重要的设计决策。业务流程分析员为每个构架视图建立整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与定义组织的其他工件相比，业务构架文档提供宽度的视图，而不是深度的视图。业务对象模型业务对象模型是描述业务用例实现的对象模型。下列人员使用业务对象模型： 业务流程分析员，负责模型的完整性。 业务设计员，记录有关人员承担的职责和那些由模型中的业务所生成或使用的“事件”的详细信息。 系统分析员，使用该模型来确定系统主角和系统用例。 设计员，使用该模型来确定分析设计模型中的类。业务流程分析员负责业务对象模型的完整性，确保： 组织单元正确地表示业务的结构。 将业务角色集中在一起就可以涵盖业务中的所有职责。 将业务实体集中在一起就可以涵盖在业务中生成和使用的所有“事件”。补充业务规约本文档中提供了一些必要的、但未包括在业务用例模型和业务对象模型中的业务定义。此文档供业务设计员、系统分析员和构架设计师阅读。业务流程分析员负责补充业务规约的完整性，此规约是对业务用例模型和业务对象模型的一个重要补充。补充业务规约、业务用例模型和业务对象模型这三项应该能记录下了解系统环境所需的所有业务信息。业务用例业务用例（类）定义一组业务用例实例，其中每个实例都是业务执行的一个操作序列，对于特定的业务主角来说，操作序列所产生的结果是可见值。下列人员使用业务用例： 分析、设计和实施系统的人员，使用业务用例实现来理解要构建的系统的环境。 系统分析员，使用业务用例实现得出系统需求。 经理，使用业务用例来更好地了解要构建的系统的环境、目的和重要性。业务流程分析员负责用例的完整性，确保： 业务用例正确地描述组织开展业务的方式。 工作流程说明简明易懂且适用于其目的。 来源于业务用例的包含关系和扩展关系合理且保持一致。 通信关联关系中包括的业务用例的角色清楚而又直观。 描述业务用例及其关系的图简明易懂，并适用于相应的说明目的。 特殊需求简明易懂，且符合设计目的。 前置条件简明易懂，并适用于其目的。 后置条件简明易懂，并适用于其目的。组织单元组织单元是业务角色、业务实体、关系、业务用例实现、图和其他组织单元的集合。组织单元通过将该模型分成若干小的部分，来建立业务对象模型结构。业务设计员使用组织单元来给业务角色和工件分组。业务设计员负责组织单元的完整性，确保： 组织单元正确反映组织的结构业务主角业务主角代表了与业务有关的角色，此角色由业务环境中的某个人或物扮演。下列人员使用业务主角： 业务系统分析员，在定义组织的边界时使用； 业务设计员，在描述业务用例以及用例与业务主角的交互时使用； 用户界面设计员，在记录关于人员 系统主角的特征时使用； 系统分析员，在查找 系统主角时使用；业务流程分析员负责业务主角的完整性，确保： 每个（人员）业务主角都获取必要的特征。 每个业务主角与其参与的业务用例之间都建立正确的通信关联关系。 每个业务主角都是正确的泛化关系的组成部分。 每个业务主角都定义一个内在关联关系的角色，且与其他业务主角无关。 描述业务主角的局部用例图不仅具有可读性，而且与其他特征保持一致。业务实体业务实体是被动类；即它本身不能启动交互。业务实体对象可参与许多不同的业务用例实现，并且通常生存期比任何单个的交互更持久。在业务建模中，业务实体代表业务角色访问、检查、操纵、生成等的对象。下列角色使用业务实体： 业务设计员，描述业务实体以解释业务中的某个“事物”或产品。 系统分析员，在描述系统用例时将业务实体作为输入内容使用。 设计员，使用业务实体作为确定设计模型中的实体的输入。业务设计员负责业务实体的完整性，确保： 名称和简要说明可以解释相关问题。 职责得到正确描述。 适当定义业务实体的关系、属性和操作以完成其职责。业务角色业务角色是一个类，是在系统中发挥作用的人的抽象。参与业务用例实现时，一个业务角色和其他业务角色交互，操纵业务实体。下列人员使用业务角色： 业务设计员描述业务角色，用于解释业务中的一个或一组角色。 系统分析员，在确定系统主角和用例时，将业务角色用作输入。业务设计员负责业务角色的完整性，并确保： 名称和简要说明可以解释相关问题。 职责得到正确描述。 业务角色具有为履行其职责而指定的适当的关系、属性和操作。业务用例实现业务用例实现说明就协作对象（业务角色和业务实体的实例）而言，如何在业务对象模型范围内实现特定的业务用例。下列人员使用业务用例实现： 分析、设计和实施系统的人员，使用业务用例实现来理解要构建的系统的环境。 业务设计员，使用业务用例实现说明如何在组织中执行流程。 系统分析员，使用业务用例实现得出系统需求。 经理，使用业务用例实现了解要构建的系统的环境、目的和重要性。业务设计员负责业务用例实现的完整性，以确保： 正确解释源自业务用例的工作流程说明。 业务角色和业务实体之间的关系保持一致，并且实现工作流程。 描述业务用例实现及其关系的图简明易懂，符合设计目的。5.2 需求工件集需求工件集获取并提供定义系统必备功能时要用到的信息。表 12 工件 需求工件集工件名称描述目的职责需求管理计划说明需求文档、需求类型以及各自的需求属性，同时指定出于对项目需求进行评测、报告和控制等目的而要收集并使用的信息和控制机制。应该制定需求管理计划，以便指定一些要收集的信息和控制机制，用于评测、报告和控制对产品需求的变更。 需求管理计划的目的是说明项目如何设置需求文档、需求类型以及各自的需求属性和可追踪性。系统分析员负责创建需求管理计划。前景前景是项目核心需求的概览，并为更详细的技术需求提供了契约性的依据。前景文档有时可作为更详细的技术需求的高层次契约性依据。还可以有一个正式需求规约。前景文档记录了相当高层次的需求和设计约束，便于读者了解正在开发的系统。它为项目认可流程提供输入，因此与商业理由密切相关。它传达了与项目有关的最根本的“什么和为什么”的问题，将来确认所有决策时都应以此为标准。经理、出资方、用例建模中的角色和所有开发人员将阅读前景文档。系统分析员负责维护前景文档的完整性，并确保： * 前景文档保持最新状态并已分发。 * 来自所有相关涉众的输入都予以考虑。词汇表词汇表定义项目中所使用的重要术语。该系统有一个词汇表。此文档对于许多开发人员来说非常重要，尤其是当他们需要了解和使用该项目的特定术语时显得更为重要。系统分析员负责词汇表的完整性，确保： * 词汇表能及时生成。 * 始终与开发结果保持一致。涉众请求本工件包括了涉众（客户、最终用户、营销人员等）可能就所开发系统提出的任何类型的请求。它还可能包含对系统必须符合的任何类型的外部来源的引用。该工件的目的是记录对项目发出的所有请求，以及这些请求的受理程度。尽管系统分析员是该工件的负责人，但很多人都会参与进来，如：营销人员、最终用户和客户，这些人可以是项目结果涉及的任何涉众。该信息可使用文档或自动化工具进行收集，而且变更请求管理 (CRM) 流程一经认可，就应记录并报告适当的请求。涉众请求来源的示例如下： * 涉众访谈的结果（请参见下文对一个脚本模板示例的提纲） * 有关获取需求的讨论会和研讨班的结果 * 变更请求 (CR) * 工作说明 * 方案征求 * 任务说明 * 问题说明 * 业务规则 * 法律和法规 * 遗留系统 * 业务模型系统分析员负责涉众请求工件的完整性，并确保： * 每个涉众都有机会提出请求。 * 在制定用例模型和补充规约中的详细需求时，应考虑到该工件中的所有项用例模型用例模型是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。下列人员使用用例模型： * 客户认可用例模型。在获得了认可之后，您就可以确认系统正是客户所预期的。您也可以在开发过程中使用模型与客户就系统展开讨论。 * 潜在用户使用用例模型来更好地理解系统。 * 构架设计师使用用例模型来确定关键构架功能。 * 设计员使用用例模型来获取有关系统的概述。举例而言，您在改进系统时需要有关用例模型的文档来辅助改进工作。 * 经理使用用例模型来计划并跟踪用例建模以及后续设计。 * 组织内的非项目人员、经理和指导委员会使用用例模型了解已做的工作。 * 有关人员复审用例模型，定期为开发人员提供适当反馈。 * 设计员将用例模型作为其工作的基础。 * 测试员使用用例模型尽可能早地制定测试计划活动（用例测试和集成测试）。 * 开发系统下一个版本的人员使用用例模型来了解现有版本是如何工作的。 * 文档编写员将用例作为编写系统用户指南的基础。系统分析员负责用例模型的完整性，并确保用例模型在整体上正确、一致和简明易懂。当用例模型描述且仅仅描述了系统的功能时，用例模型就是正确的。请注意用例包、用例、主角、关系和图的详细说明是相应用例阐释者的职责。有关详细信息，请参见角色：用例阐释者。用例视图属于构架设计师的职责范围。有关详细信息，请参见角色：构架设计师。需求属性此工件包含从需求管理的角度看需要跟踪的项目需求、属性和依赖关系的储存库。需求属性工件为所有需求提供一个储存库，其中包括需求文本、属性和可追踪性。开发组织中的所有人员应该都可以访问它。系统分析员负责需求属性工件的完整性，确保： * 已更新并分发需求属性储存库的内容。 * 已经考虑了来自有关各方的输入。补充规约补充规约记录那些在用例模型的用例中不容易体现出来的系统需求。这些需求包括： * 法律法规方面的需求和应用标准。 * 要建立的系统质量属性，包括可用性需求、可靠性需求、性能需求和可支持性需求。 * 其他需求，诸如操作系统和操作环境、兼容性需求以及设计约束。下列人员使用补充规约： * 系统分析员创建并维护补充规约，此规约用作系统分析员、客户和其他开发人员之间的交流媒介。 * 设计员对类定义职责、操作和属性并且调整类使其适应实施环境时引用补充规约。 * 实施员实施类时在补充规约中查找输入。 * 经理计划迭代时在补充规约查找输入。 * 测试员使用补充规约来核实系统的一致性。系统分析员负责生成补充规约，该规约是对用例模型的重要补充。补充规约和用例模型应该一起获取对系统的一整套需求。用例用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。以下人员将使用用例： * 客户，使用用例来理解系统的行为。由于客户必须认可用例事件流，所以要使用用例来认可用例建模的结果。 * 潜在用户，使用用例来理解系统的行为。 * 构架设计师，使用用例确定关键构架功能。 * 分析、设计和实施系统的人员，使用用例来理解必需的系统行为并改进系统。 * 用例设计员，使用用例事件流来发现类。(对用例设计员而言，这些是最重要的工件) * 测试员，使用用例作为确定测试用例的基础。 * 经理，使用用例来计划并跟踪用例建模。 * 文档编写员，使用用例来理解在文档（如系统用户指南）中应当描述何种使用顺序。用例阐释者负责用例的完整性，以确保： * 用例满足其需求（即正确阐述而且只阐述与用例有关的功能）。 * 事件流简明易懂且适用于其目的。 * 源自用例的用例关系合理且保持一致。 * 通信关联关系中涉及的用例角色清楚且直观。 * 描述用例及其关系的图简明易懂，并适用于相应的说明目的。 * 特殊需求简明易懂，并适用于其目的。 * 前置条件简明易懂，并适用于其目的。 * 后置条件简明易懂，并适用于其目的。用例包用例包是用例、主角、关系、图和其他包的集合，通过将用例模型分成若干个较小的部分来建立用例模型。下列人员使用用例包： * 系统分析员使用用例包来建立用例模型。 * 捕获有关系统下一版本需求的人员使用用例包理解用例模型的结构。 * 用例阐释者将用例包作为一种参考，用于他们自身所从事的系统部分之外的其他部分。 * 测试员将用例包作为制定测试计划活动的输入。用例阐释者负责包的完整性，以确保： * 包满足其需求。 * 各包之间尽可能独立。 * 包的直接内容（包括其用例、主角、关系、图和包）的存在合理且保持一致。建议负责用例包的用例阐释者同时负责用例包所包含的用例。软件需求规约软件需求规约 (SRS) 记录对系统或系统的一部分的完整软件需求。使用用例建模时，本工件由一个包组成，该包包含用例模型的用例和适用的补充规约。下列人员使用软件需求规约： * 系统分析员创建并维护前景和补充规约，它们将用作对 SRS 的输入，并充当系统分析员、客户和其他开发人员之间的交流媒介。 * 用例阐释者创建并维护单个用例和 SRS 包的其他构件， * 设计员在定义类的职责、操作和属性时，或在调整类使其适应实施环境时参考该 SRS 包。 * 实施员实施类时在 SRS 包中查找输入。 * 项目经理计划迭代时在 SRS 包中查找输入。 * 测试员使用 SRS 包来核实系统的一致性。用例阐释者负责生成软件需求规约 (SRS) 包，它是对用例模型的一个重要补充。SRS 包收集适合的补充规约和用例模型的用例，它们一起记录对系统或确定的子系统的一整套需求。主角主角定义系统用户在与系统交互时可扮演的一组相关角色。用户可以是个人，也可以是外部系统。下列人员使用主角： * 用户界面设计员，在记录人员主角的特征时使用； * 系统分析员，在查找系统边界时使用； * 用例作者，在描述用例以及用例与主角的交互时使用； * 对象分析员，在实现用例以及用例与主角的交互时使用；用户界面设计员负责人员主角的完整性，确保： * 每个主角都获取构建用户界面所必需的特征。 * 每个主角与其参与的用例之间都建立正确的通信关联关系。 * 每个主角都是正确的泛化关系的组成部分。 * 每个主角都定义一个内在关联关系的角色，且与其他主角无关。 * 描述主角的局部用例图不仅具有可读性，而且与其他特征保持一致。除特征以外（上述第一项），系统分析员与非人员主角的职责相似。用例示意板用例示意板是关于用户界面如何提供用例的逻辑和概念说明，包括主角和系统间必需的交互。下列人员使用用例示意板： * 用户界面设计员，使用用例示意板建立用户界面的模型； * 用例设计板涉及的边界对象的设计员，使用用例示意板理解用例中对象的角色及其交互方式，并利用这一信息设计和实施边界对象（例如，构建用户界面）； * 设计系统下一版本的人员，使用用例示意板理解系统就边界对象而言执行事件流的方式。例如，变更可以影响有限数目的用例，此时设计者需要见到其事件流的实现； * 测试员，使用用例示意板测试系统的用例； * 经理，使用用例示意板计划并跟踪分析设计工作。用户界面设计员负责用例示意板的完整性，并确保： * 事件流示意板简明易懂并适用于其目的； * 描述用例示意板的图简明易懂并适用于其目的； * 可用性需求简明易懂并适用于其目的，且它们正确记录了用例模型相应用例的可用性需求； * 用例模型中对相应用例的跟踪依赖关系正确； * 用例模型中相应用例的关系，如通信关联关系、包含关系和扩展关系等，在用例示意板中得到很好处理。用户界面原型用户界面原型是用户界面的一种原型。例如，原型自身可表现为： * 画在纸上的草图或图片； * 用绘图工具绘制的位图； * 交互式的可执行原型。下列角色使用用户界面原型： * 用例阐释者，用来了解用例的用户界面； * 系统分析员，用来了解用户界面如何影响系统分析； * 设计员，用来了解用户界面如何施加影响及它对系统“内部”的要求； * 类测试人员，用来制定测试计划活动。用户界面设计员负责维护用户界面原型的完整性，并确保按照用例示意板和边界对象的要求，使用原型构建一个可用的用户界面。边界类边界类建立一个或多个主角与系统之间的交互模型。边界类表示系统与系统外的某个实体（个人或另一系统）之间的接口。其作用是促成系统与外界交换信息，并使系统不受外界环境变化的影响。用户界面设计员或对象分析员负责边界类的完整性，确保： * 类必须满足由该类所参与的用例实现和用例示意板所确定的需求。 * 各类之间尽可能独立。 * 类的特征，包括它的职责、单向关系和属性，需要调整并且彼此之间保持一致。 * 具有双向关系的类涉及的角色清楚而又直观。 * 其成员的可见性（主要指属性）正确。可见性可为“公有”、“私有”等等。 * 其成员的范围（主要指操作和属性）正确。对于类型/类范围来说，范围是“真”；而对于对象/实例范围来说，范围是“假”。 * 特殊需求简明易懂，且符合设计目的。 * 说明类的图简明易懂且与其他特征一致。5.3 分析设计工件集工件集分析设计工件集获取并提供解决方案（针对需求集内提出的问题）的有关信息。表 13 工件 分析设计工件集工件名称描述目的职责部署模型部署模型显示运行时处理节点的配置、各节点之间的通信链接，以及驻留在这些节点上的构件实例和对象。部署模型的目的是获取系统中处理元素的配置以及这些元素之间的连接。构架设计师负责部署模型。参考构架参考构架实质上是一个预先确定的构架模式或一组构架模式，可以部分或完全实例化。根据设计并经过证实可用于特定的业务和技术环境，使用时常要用到一些辅助性的工件。通常从以前的项目中获取这些工件。参考构架工件是组织的可复用资产库的一部分。这些工件的目的是为构架开发建立一个起点。它们可以是现成的构架模式、构架机制和框架，也可以是具有已知特征并证实已在使用的完整系统。构架设计师负责选择并使用参考构架。软件构架文档通过采用许多不同的构架视图描述系统的各个方面，软件构架文档从构架的角度对整个系统进行综合概述软件构架文档提供软件系统构架的综合概述。它用作构架设计师和项目团队的其他成员之间的交流媒介，讨论已针对项目构架做出的重要决定。构架设计师负责编写软件构架文档，此文档记录多个构架视图中最为重要的设计决策。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此，与其他角色相比，构架设计师的视图属于宽度视图，而不是深度视图。构架工程师还负责在整个开发流程中维持系统的构架完整性，具体方式如下： * 认可对在构架方面很重要的元素（如主要接口）所做的更改，软件构架文档对这些元素进行了说明。 * 参与“变更控制委员会”决策，以解决那些影响软件构架的问题。协议封装体端口集的常用规约。协议允许指定一组工件：封装体端口，以对之进行定义和复用。构架设计师负责协议的完整性，确保协议定义的完整性和一致性。接口定义行为集（即操作集）的模型元素，该行为集由分类符模型元素（即类、子系统或构件）提供。分类符可以实现一个或多个接口。一个接口可由一个或多个分类符实现。实现相同接口的那些分类符在系统中可以互换。每个接口应该提供唯一且明确定义的操作集。接口声明一组操作