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