概念:
|
活动 | 工件 | 可用性相关内容 |
---|---|---|
引发涉众请求 | 涉众请求 |
此活动包括会见用户、问卷调查和召开研讨会,以更好地了解用户和用户环境。这包括以下内容:
|
制定远景 | 远景 |
远景模板的用户环境部分描述最终用户的工作环境,即 ISO 所称的环境上下文 [ISO 13407] 。 远景模板的用户概要信息部分描述用户的专门技术、技术背景、职责、成功条件和可交付工件等。这是 ISO 所称的用户上下文 [ISO 13407] 。 |
查找参与者和用例、构造用例模型、详细描述用例 | 用例模型 |
用例模型描述用户(参与人员)所执行的任务(用例)。它使用泛化关系获取参与者之间的相似性和关系。参与者通过这种关系与用例相关,这类似于 Constantine 的“角色模型”[CON99]。用例得以构造,并通过通信关联、包含、泛化和扩展关系相互相关以及与参与者相关。 研讨会是让用户参与的极佳方式。请参阅: |
|
参与人员的特征是作为参与者的属性来捕获的。这些属性包括:
|
|
|
这些可包括 Constantine [CON99] 中所述的基本用例(有关基本用例的讨论,请参阅概念:以用户为中心的设计)。给定用例的特定可用性需求可作为“特殊需求”记录在![]() |
|
详细描述软件需求 | 补充规范记录用例中未指定的需求。这包括可能与可用性密切相关的可用性和性能需求。在此获取适用于多个用例的一般可用性需求,以及适用的法规和可用性标准(有关可用性法规和标准的详细信息,请参阅概念:以用户为中心的设计)。 | |
复审需求 | 变更请求 | 以用户为中心的开发工作使尽可能多的用户参与所有需求复审。 |
获取常用词汇表 | 词汇表 | 获取特定于用户领域的常用词汇表术语,促进用户与开发团队其余成员之间的交流和理解。 |
除了上述需求活动外,其它的一些技术可能也有用。
此规程中的许多其它活动均注重用户界面的成形和设计。这些活动有:
活动
|
工件 |
可用性相关内容 |
---|---|---|
设计用户界面 |
此项活动创建通常所称的概念设计 [FER01]。这是用户界面自身的初始抽象,获取呈现给用户的主窗口和导航路径。这项活动注重于推动用户界面设计的用例。 导航图(请参阅 [CON99])概述了交互空间(屏幕、窗口和对话框)之间的导航路径。 |
|
制作用户界面原型 | 用户界面原型 |
可以制作三种基本原型: 绘图(在纸上) 创建用户界面原型主要是为了能够在实际设计和开发工作开始之前展示和测试系统的功能性和可用性。这样,可以确保您正在构建正确的系统,以免在开发上花过多时间和资源。 |
作为设计用户界面的一部分,以下技术可能也是有用的:
除了上述活动外,以下分析与设计活动是对用户界面设计的补充:
活动
|
工件 |
可用性相关内容 |
---|---|---|
用例分析 | 分析类、 用例实现 |
另请参阅以下内容: |
类设计 |
这项活动使用了设计用户界面和制作其原型的结果,并设计类。不同于原型,这不是一次性概念的用户界面工作,而是旨在表示所提供系统的设计。 另请参阅以下指南: |
用户界面的实施遵循一般的实施工作流程。请注意,用户界面的实施通常是作为设计活动的一部分来进行的。
一旦有了用户界面的实体模型或可执行原型,就应开始可用性测试(包括可用性相关的性能测试)。测试应包括验证可用性和记录在补充规范中或作为“特殊需求”记录在
用例规范中的性能需求。
用户应着重参与工作流程明细:Beta 测试产品以及
工作流程明细:管理验收测试期间的最终可用性测试。
工作流程明细:制订支持材料包括制订培训材料和系统支持材料,以确保最终用户可成功使用所提供的软件产品。
项目管理是一门艺术,它平衡各种竞争的目标、管理风险、并克服约束而成功提供符合客户(帐单支付者)和用户需要的产品。从可用性设计的角度来看,最关键的活动是活动:定义项目组织和人员配备。这项活动定义了组织结构、外部界面以及角色和职责。这包括定义用户将在多大程度上参与开发流程,以及确定开发人员是否应具备可用性设计方法的经验。
环境规程包括项目或组织将要遵循的开发流程的定义。
活动:制定开发案例(
工件:开发案例)定义将要应用的可用性设计技术,以及将如何定制各种 RUP 工件和活动来包容这些技术。
另一项重要活动是活动:制定特定于项目的指南,该活动创建的
工件:项目指南包含了用户界面指南。这些指南有助于确保用户界面的一致性,这会对可用性大有帮助。它们还包括要遵循的可用性准则,如关于快捷方式、“撤销”功能、可识别出口和无模式交互等的指南。
RUP 的软件生命周期在时间上分为四个连续的阶段,每个阶段以一个主里程碑结束;每个阶段基本上是两个主里程碑之间的时间段。在每个阶段结束时执行评估,以确定是否已达到阶段的目标。如果评估令人满意,则允许项目进入下一个阶段。
每个阶段中都可能有几个迭代。迭代是完整的开发循环,生成的是可执行产品的发行版(内部或外部),这是开发中的最终产品的一部分,会通过一次次的迭代逐渐发展为最终系统。可用性由此迭代方法大为受益。它可使用户提供关于可用性的早期反馈,并避免朝着完全不符合用户需要的道路走得太远。
用户应参与每一次迭代,以进一步优化需求、评估设计概念以及测试/评估概念证明原型和发展中系统的可用性。
以下各节描述可用性相关阶段的完成条件和每个阶段的主要活动。
先启阶段的两个关键目标是:
从可用性设计角度来看,这意味着强调与以下因素相关的需求和业务建模活动:
在先启阶段,常常还探索某种概念性设计和制作“概念证明”原型。当主要项目风险与用户界面和可用性问题相关时,尤其如此。一旦有了用户界面的实体模型或可执行原型,就应开始可用性测试(包括可用性相关的性能测试)。
因为 RUP 是迭代流程,在先启阶段创建的工件由用户反复访问和复审,以控制范围和确保发展中系统符合用户需要。
在精化阶段,注重的是软件体系结构 - 包括用户界面的体系结构。定义概念性用户界面,并实施用户界面设计的关键和/或风险元素。与软件体系结构相关的活动通常适用于用户界面 - 有必须评估的现成产品、重用注意事项以及机制和模式的选择等等。
此阶段强调用户界面设计活动,以及分析与设计规程中的支持活动。也涉及到实施和测试,因为完成精化则需要构造可评估的运行系统。
可用性测试和可用性相关的性能测试应注重于在补充规范中记录的或作为“特殊需求”记录在
用例规范中的任何风险需求。
在构造阶段,注重的是实施更多用例。这包括对用户界面的补充,同时保持用户界面的概念性模型和在特定于项目的指南中记录的用户界面指南正确。可用性测试在添加新功能时仍非常重要。
每个迭代中所放置功能的选择是以针对用户的价值为基础的。
移交阶段的注重点开始转向部署规程。在以用户为中心的开发工作中,不应等到移交阶段才让用户参与。不过,继续让用户参与主要是为了提供反馈。当在整个开发过程中让用户参与时,正式的 beta 测试和验收测试常常会明显减到最少或不存在。相反,详细的用户反馈和核准意见会出现在整个开发工作中。
培训材料和系统支持材料的制定是在移交阶段完成的,但这项工作应尽可能在较早阶段开始,以得到用户反馈。
在移交阶段,存在可由最终用户使用的工作系统。在移交阶段至少计划几个迭代,这样就可以更正初始发行版中的问题并容纳关键用户反馈,这是个好主意。
Rational Unified Process
|