GB T 23700-2009 人-系统交互人类工效学.以人为中心的生命周期过程描述.pdf

《GB T 23700-2009 人-系统交互人类工效学.以人为中心的生命周期过程描述.pdf》由会员分享，可在线阅读，更多相关《GB T 23700-2009 人-系统交互人类工效学.以人为中心的生命周期过程描述.pdf（25页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 13. 180 A 25 一GB/T 23700 2009/ISO/TR 18529 :2000 主监-命主=口E马F 日Ergonomics Ergonomics of human-system interaction Human-centred lifecycle process descriptions (ISO/TR 18529: 2000 , IDT) 2009-05-06发布2009-11-01实施户今品与传怦内J、V JMl立在mz中华人民共和国国家质量监督检验检亵总局中国国家标准化管理委员会发布GB/T 23700 2009/月2主18529.2000目次E 引言. .

2、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . W 1 范围-2 规范性引用文件3 术语和定义4 缩略语. . . . . 5 以人为中心过程模型的背景5. 1 模型应用5.2 生命周期中使用以人为中心方法的益处. . . . 4 5.3 模型的基本原理. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.4 模型的基础. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3、 5.5 模型的结构. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.6 模型的元素. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.7 模型与ISO/TR15504的关系. . . . . . . . . . . . . . . . . . . . . . . . . 6 5.8 模型与ISO12207的关系. . . . . . . . . . . . . . . . . . . . . . 7 6 以人为中心的过程. . . . . . .

4、. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. 1 以人为中心的设计. . 6.2 确保在系统策略中包含HCD的内容CHCD.l)6.3 规划和管理HCD过程(HCD.2). . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4 确定利益相关方和组织的需求CHCD.3)6.5 理解和确定使用情境CHCD.4). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.6 提出设计解决方案CHCD

5、.5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. 7 针对需求评估设计. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 6.8 安装和运行系统CHCD.7). . . . . . . . . . . . . . . . . . . . . . . . . 12 附录AC资料性附录)相关工作产出人1以人为中心生命周期过程相关工作产

6、出列表附录B(资料性附录)以人为中心生命周期过程的应用B. 1 过程定义中的模型应用. . . B.2 过程改进中的模型应用B.3 过程评估中山回四川，因附录C(资料性附录)过程模型中对描述的应用C.1 简介C.2 模型目的C.3 模型范围. . . . . C.4 模型元素C.5 图谱参考文献14 14 17 17 17 17 19 19 19 19 19 19 20 I 5 . . . . . . . . . . . . . . . . . . :2000 . . . 18529 . . . . . 23700 2009/ISO/TR . . . 实体关系图GB/T 1 图5 . . .

7、. 以人为中心设计过程及其实践2 6 14 . . . . . . . . . . . . 1) 的内容) 6.5 理解和确定使用情境(HCD.4)6.5. 1 目的本过程的目的是辨别、明确和记录利益相关方及其任务、系统运行环境的组织特性和物理特性。本过程的成功实现会给出如下结果z对目标用户的特征定义F用户需完成的任务定义z系统应用组织和环境定义;设计含义的清晰表达3该使用情境是可用的，并应用于生命 相关节点。注2本过程与GB/T18976-2003的7.2理解和确定使用背景直接相关。上述目的可以通过如下。6.5.2 确定和记录用户任务(HCD.4.1)描述用户为达到系统目标进行的活啊。注12

8、根据用户和组织的活动描述任务，而不仅是根据设备功能或特征描述任务。注22在系统生命周期中任务可能会改变或演化).6.5.3 确定和记录重要的用户特征(HCD.4. 2) 描述系统最终用户的相关特性。这包括知识、语言、生理特征、工作任务和使用相关系统设备的经、使用系统的动机、优先权等。6.5.4 确定和记录组织环境(HCD.4. 3) 描述相关的社会和组织环境、管理机制、沟6.5.5 确定和记录技术环境(HCD.4. 4) 在系统的使用情境中描述所有设备的相关特性。和组织业务等。别注意与用户直接交互的设备。注=对于新系统，设备特性是依赖于系统设计解决方案的(见HCD5.4及5.日，而且直至生命周

9、期的较晚阶段才能够了解.6.5.6 确定和记录物理环境(HCD.4. 5) 述工作地点、工作场所设备和周围环境及其在设计中的含义。如，照明、噪声、振动等。6.6 提出设计解决方案(HCD.5)6.6. 1 目的本过程的目的是通过参照已有完备的实践、利益相关方的经验和知识以及建可能的设计解决方案。本过程的成功实现会带来如下结果g10 在设计中考虑整个社会技术系统中所有技术成分的运行p在系统采购时考虑用户特征和需求z在系统设计中考虑用户特征和需求;社会技术工程学、人类工效学、心理学、认知科学和其他相关学科中，、结果，创的知识会被GB/T 23700 2009/ISO/TR 18529: 2000

10、整合到系统中s由于设计决策将会变得更清晰，系统利益相关方之间的交流也会得到改善p开发团队将能在确定设计方案之前研究几种不同的设计恩怨;最终用户及其他利益相关方的反馈，能够应用于开发过程早期的设计阶段s有可能进行迭代评估和备选方案评估;设计用户与系统软硬件和组织成分的界面p开发用户培训和支持方案。注=本过程与GB/T18976-2003中7.4提出设计方案直接相关.上述目的可以通过如下实嗣冉、刮目6.6.2 分配功能(HCD.5.1)分析使用情境和系统性能，以最佳方式在系统的人员、机器和组织之间分配功.0 注12功能的分配可能是动态的.目的在于按照系统的目标使整个系统的性能最优化.注22在系统分

11、层树的较高层，功能可能不会被分配到特定的人员、组织、软件或硬件成分，而是分配到由多个成分构成的子系统.注3:对于功能分配，任务分析(HCD4.1)是使用情境中最重要的成分.6.6.3 提出组合任务模型(HCD.5. 2) 、需求、使用情境、功能分配、设计约束等方面的已有知识出发，为用户的开发可行的模型.注:HCD. 5. 1到5.3在系统分层树的每个层次上实现.HCD. 5. 4到5.8则在系统成分定义和开发的层次上实现.6.6.4 研究系统设计，以了解评估员资格、评估相关的质量过程等细节。第一步是评估前的模型修订二这包括相关过程的选择和可能的最大能力定义。所选择的过程应能代表企业进行的活动。

12、模型并非不可更改，而是耳以按需要进行修订。评估的目的通常是为了清楚地了解特定企业的过程，进而对这些过程加以改善。只有当修订的模型能适应评估目标时，评估业获得收益。如果企业希望知道特定活动的进行情况，则选择相应的过程和实践进行评估。如果特定过程的进行情况对企业并不重要，则没有必要对其进行评估。在以鉴定认证为目的的第三方评估中，情况则有所不同。购买者或其他客户需要来自企业的队抽，以确认必要的过程按照其标准执行。在此种情况下，评估需要涵盖的过程由客户决定。下一步是选择评估所需的典型项目。对于完全评估，选择的项目范围应在工作场所、项目大小和企业投入方面具有代表性的过程。会见选定的职员来进行评估。首先，

13、确定每个过程进行了哪些实践。其次，按ISO/IECTR 15504(信息技术软件过程评估的第5部分中定义的管理实践性能标准，确认这些过程执行的情况。本标准附录A中提供的工作产出列表可能会作为实践性能的依据。被访者的准备会有利于评估的进行。他们需要理解模型，以及进行评估的原因，需要对过程有一定的熟悉度。被访者可以按照附录A中所描述的工作产出的形式提供实践性能的依据。GB/T18976 GB/T 23700 2009/ISO/TR 18529 :2000 2003对为以人为中心过程评估获得依据提供了指导。被评估的企业需要理解评估工作，并为之作准备。在理想状况下，相关职员应对进行研究，并与实践如何与

14、以人为中心生命周期过程相匹配作出说明。总体上，访谈一名项目经理和2至3名项目职员(职员们可一同访谈)，即足以提供项目理解释。度的合为了鼓励开放和合作，对实践能否执行的评估是非正式的。最好要求被访者描述过程如何进行，只有当描述不清楚时才针对特定的实践或交付项目提出特定问题。讨论结束时，将结果进行总结，并以各项工作是否进行或是否交付的结果反馈给被访者。在性能评估中，建议开始时引导被访者描述过何管理，接着按照最低的成熟度水平提出问题，然后逐渐提高，直到实践明显不能完成的水平为止。超过这一水平并无好处。如果被访者没有准备或时间紧急，评估者也可以直接提问。行评对于每个被访者，从N到F为每项实隔町万2N

15、未完成z无任何依据显示规定的实践已被完成。P 部分完成g规定的实践已部分完成。L 大部分完成2规定的实F全部完成=规定的实践已评分时尽量给出较高的.JJ男人。主要完成。成。能水平只部分。使用事先准备的纸质表格或基于计算机的工具，对企业中每个涉及以人为中心活动的过程进。评估结果将成为企业中以人为中心过程审核或改进的基础。评估结果无所谓好与坏。性企业达到目标即可。所需的成熟度标准(过程性能由客户定义并作为过程改进山一B.3.2 以人为中心过程与其本模型中提供的以人为中心过程可用于扩充其他过程模型中的过程系列。对通过满足用户需求而业利益的负责开发或支持系统的组织或部门进行能力评估时，就有可能进行这种

16、扩充。在评估之前，通常要修订以人为中心过程。过程用标准格式描述，以使修订尽可能简便。选择评估中应包括的过程时，宜采纳人因专家的意见。HCD.2几乎是必需执行的。HCD.3-6有可能为大多数评估所需要。HCD.l可能与综合系统开发(如国内产品更为紧密相关，而HCD.7则与大型系统(如公共区域信息系统关系更密切。在系统生命周期的早期，HCD.2、3和4的相关性可能更高，但需注意HCD.5和6中的一些实践需要在系统开发的最初时期进行。以人为中心生命周期的重复性也意味着，HCD.3和4中的元素在系统支持中仍需执行。B.3.3 非正式评估中的模型应用上述评估方法是很严格的，以使评估结果在不同的企业中具有

17、可重复性。在一些情况下，这种程度的严格和正式是不合适的。可用于更加非正式的情况，如研讨会或讨论小组。开发过程的描述和关于管理实践是否实施的讨论仍需保留，但评分过程无需进行，或虽进行评分，但对于是否满足其特性的评估由小组集体决定。虽然结果无需记录，但关于完成的水准、业务或项目需求的标准以及达到标准所需的工作，应达成共识。小组讨论方法旨在增加利益相关方的意识。评估会上小组成员彼此间的讨论，很可能比过程改进专家的建议更有价值。即使当评估由外界评估人员进行时，也可以加入小组讨论的成分，以提高个人意识和组织知识。在非正式评估中，小组可以对自身进行评估，并保留结果作为下次讨论或项目的参照;还可以规划改进活

18、动，并应对变更进行责任分配。18 GB/T 23700 2009/ISO月R18529: 2000 附录C(资料性附录过程模型中对描述的应用C.1 本资料性附录对ISO/IECTR 15504-2信息技术软件过程评估第2部分z过程及过程性能参中给出的一致性要求提供了解释，以应用于本标准中绘出的以人为中心过程。尽管一些条目中出现了应当一词，但不应将其理解为对本标准使用者的要求。本附录描述了ISO/IECTR 15504信息技术软件过程评估与本标准中过程有兼容性的过程模。JT1l J、的目的在于，使应用了不同模型和方法的评估结果之间可以相互比较。对于不是以过程评估为目的建立过程模型的人，本标准不做

19、出任何要求。C.2 C.3 的基于良好的以人为中心原则，并适用于评估范围当包含本标准中描述的模型应当注明其涵盖范围。其中的一个非空的目的。C.4 模型元素模型应基于元素集，如第6章所定义，该元素集在模型的范围内明确阐述已经定义的所有过程。模型的详细元素应当组成一系列过程性能指标，这些指标通过工作产出体现过程的有效执行。C.5 图谱当提供一种明确的从模型基本元素到本标准中描述的过程和过程特性(目的和工作产出图用。图谱应当完整、清晰、明确，并应当包括涵盖范围的声明。图谱应当包括模型中以本标准中过程目的为基准的过程性能指标图谱。19 GB/T 23700 2009/ISO/TR 18529:2000

20、 参考文1J GB/T 18978. 11 使用终端(VDTs)办公的人类工效学要求第11部分=可用性2J GB/T 18978. 10 使用视觉显示终端(VDTs)办公的人类工效学要求10部分z对话 3J Bate R.Kuhn D. Wells C.Armitage J .Clark G.Cuskck K.Garcia S.Hanna M.Jones R.Mal pass P. Minnich 1. Pierson H. Powell T. Reichner A. (1995) A Systems Engineering Capability Matur七ty Model. Version

21、 1. 1.SE-CMM-95-01.CMU/SEI-95-MM-003.Carnegie Mellon University. Software Engineering lnstitute. 4J Brennan C. Earthy J Jennings D. (1995) Draft HCI Functions fro BCS Industry Structure Model (version 3). British Telecommunications Research Laboratories. Martlesham Heath. lpswich. UK. 5J . EIA 713 I

22、nterim Standard. Systems engineering capabi1ity model.Electronic Industries Alli ance. USA. 6 J ISO/IEC TR 15504-2: 1998 Information technology Software process assessment._ Part2: A reference model for processes and process capability. 7J IS0/IEC 12207: 1995 lnformation technology Software life cyc

23、le processes. 8 J ISO/IEC 15288 lnfrmation technology System engineering System life cycle pncesses. 9 J ISO/IEC TR 15504-9: 1998 InforInation technology Software Process assessment-Part9: Vocabulary. 口oJIS0 8402 Quality Management and Quality Assurance Vocabulary. 口1JIS0/1EC 9126-1: 2001 Software e

24、ngineering Product quality Part 1: Qua!ity model. 口2JlNUSE(l998) Usability Maturity Model. Processes.Priject lE2016 lNUSE Lioyds Regis-ter Deliverable D5. 1. 4p. Lioyd s Register House.29. Wellesley Road, Croydon. CRO 2AJ. UK www. lboro.ac. uk/eusc 13J Paulk MC, Weber CV Garcia SM.Chrissis MB,Bush M. (1993) Key Practices of the Capa bility Maturity Model. Version 1. 1. SEI-93-TR-025. Software Engineering Institute. Pittsburgh. P A. , 20