《系统与软件工程用户文档管理者的要求.doc》由会员分享,可在线阅读,更多相关《系统与软件工程用户文档管理者的要求.doc(41页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、ICS35.080L77中华人民共和国国家标准GB/T 16680XXXX/ISO/IEC 26511:2011代替GB/T 166801996系统与软件工程 用户文档管理者的要求Systems and software engineering Requirements for managers of user documentation(ISO/IEC 26511:2011,IDT)在提交反馈意见时请将您知道的相关专利连同支持性文件一并附上(本稿完成日期:2013年12月18日)XXXX - XX - XX发布XXXX - XX - XX实施GB/T 16680XXXX/ ISO/IEC 2
2、6511:2011目次前言III引言IV1范围12符合性12.1符合性的定义22.2符合性的情形23规范性引用文件24术语和定义25生存周期过程中的用户文档管理45.1软件生存周期中的用户文档管理45.2组合管理和内容管理55.3信息管理方针和策略66文档管理规划76.1文档管理任务的工作分解结构76.2用户文档编写规划86.2.1确定目标和受众86.2.2设计任务96.2.3开发任务96.2.4翻译和本地化任务106.2.5生产任务106.2.6变更管理和维护任务107用户文档计划107.1用户文档管理计划与文档编制计划107.2文档管理计划的内容117.3文档编制计划的内容128项目启动1
3、28.1授权,规程和规范128.2基础设施138.3信息开发团队138.3.1角色定义138.3.2用户文档编制的角色示例149用户文档管理控制方法179.1文档编制测量179.1.1用户文档产品测量189.1.2用户文档生产率的测量189.1.3用户文档质量测量199.1.4过程改进测量199.2文档估算2010管理控制在文档中的应用2010.1目的和成果2010.2变更管理2110.3进度和成本控制2110.4资源管理2110.4.1项目沟通2210.4.2管理文档团队成员和供方2210.4.3管理翻译服务2210.5质量管理2210.5.1管理产品质量评审和测试2210.5.2风险和问题
4、管理2310.5.3过程改进23附录A(资料性附录)文档编写计划示例24附录B(规范性附录)信息管理和软件文档管理过程31参考文献34前言本标准按照GB/T 1.12009给出的规则起草。本标准代替GB/T 166801996 软件文档管理指南。本标准对GB/T 166801996进行修订,与GB/T 166801996相比,主要变化如下:增加了第2章符合性;删除了第4章软件文档的作用;删除了第5章管理者的作用;增加了5.1生存周期过程中的用户文档管理;增加了第6章文档管理规划;第6章制订文档编制策略(见1996版)调整为本标准5.3信息管理方针和策略;删除了第7章制订文档编制标准和指南;增加
5、了第7章用户文档计划;增加了第8章项目启动;原标准第8章文档编制计划(见1996版)调整为本标准6.2用户文档编写规划删除了第9章制订文档规程;增加了第9章用户文档管理控制方法;增加了第10章管理控制在文档中的应用;10.1人员(见1996版)调整为本标准8.3信息开发团队;10.2设备(见1996版)调整为本标准8.2基础设施。本标准采用翻译法等同采用ISO/IEC 26511:2011,结合我国国情,编辑性修改内容如下:删除6.2.4“注:翻译和本地化工作宜由以目标语言为母语的工作者完成或者在目标语言所在的地区进行”删除8.3.2.14“翻译者的母语宜是目标语言”;修改9.1,将示例中“单
6、词”改为“文字”;修改10.3,将示例中货币单位由“欧元”修改为“人民币”。本标准由全国信息技术标准化技术委员会(SAC/TC 28)提出并归口。本标准起草单位:本标准起草人:GB/T 16680的历次版本发布情况为:GB/T 166801996。引言软件用户文档的有效管理是必不可少的工作,它能确保用户文档可用、准确,并能高效地形成与软件相匹配的文档资料,在用户需要时按时交付。本标准主要讨论用户文档的管理,包括软件和用户文档从初始开发到后续发布的整个过程中的所有用户文档管理工作。任何使用应用软件的人员都需要准确了解软件是如何帮助用户完成任务的。文档可能是第一个呈现在用户面前的有形产品,因此它将
7、影响着用户对产品的第一印象。如果文档表现形式便捷,很容易查找和理解,那么用户可以快速熟练地使用该软件产品。因此,文档编制过程的良好管理不仅能够帮助用户,还有益于降低培训和支持成本,同时也提高了产品、生产商和销售商的声誉。虽然许多软件设计者希望通过在设计中使用户界面更加直观的方法来减少独立文档的编写,但是这种方法事实上几乎是不可行的。用户文档是可用的软件产品的必不可少的组成部分。文档编制通常被认为是软件完成后的工作。然而,对于高质量的软件文档来说,它的编制宜从软件规划和设计阶段就开始,是软件生存周期过程的一个不可缺少的组成部分。正确的做法是:文档编制或信息管理需要有自己的过程和计划,来规划和完成
8、其包含的各项工作内容。本标准有助于使用以下两个标准的用户:ISO/IEC 15288:2008 系统和软件工程 系统生存周期过程,和ISO/IEC 12207:2008 系统和软件工程 软件生存周期过程,帮助他们把管理软件用户文档作为软件生存周期中的一部分工作。本标准从管理者的角度定义了软件文档编制过程。用于帮助他们制定、执行和评估用户文档的管理工作。注: 其他ISO/IEC 265NN系列国际标准描述的文档编制和信息管理过程,是从文档设计人员/开发人员,测试和评审人员,需方和供方的观点阐述的。本标准适用于生产一系列文档的个人或组织,也适用于开发单文档项目的组织,同样适合团队内部以及外包文档编
9、制的情况。除了用户手册,帮助系统,以及单独软件产品文档集的开发和生产以外,它还适用于更广泛的文档管理情况,包括安装、实施、管理和操作软件的最终用户所需要的文档。通常情况下,用户文档管理者还负责用于如下情况的信息(内容管理)的开发和重用: 随着软件版本的更新,多次更新用户文档; 多次重用或调整信息以支持相关的软件产品; 用户文档多个版本的翻译或本地化; 同时管理组织内一组不相关的文档项目。本标准的目的不是提倡文件的印刷或电子(屏幕)媒体的使用,或任何特定信息管理、内容管理、文档测试,项目管理工具或协议的使用,而是要求是尽可能的媒体独立。本标准适用于包含软件系统的用户文档编制工作,也适用于单独的软
10、件用户文档编制工作。35系统与软件工程 用户文档管理者的要求1 范围本标准支持软件用户对文档一致性、完备性、准确性和可用性的要求。它为文档管理者提供策略、规划、执行和控制。它指明贯穿整个软件生存周期的用户文档管理过程。它也包括用户文档管理的关键过程,即文档编制计划和和文档管理计划。本标准提供了软件文档编制和用于文档编制的信息管理过程的概览。同时还描述了用于文档编制的组合计划和内容管理。具体来说,它专注于以下内容: 项目启动时的管理要求,包括建立过程和规范,建立基础设施,建立团队并列举用户文档团队所需要的角色; 文档管理控制所需的测量和估算; 对用户文档编制工作进行管理控制; 支持过程的运用,例
11、如变更管理,进度和成本控制,资源管理,质量管理和过程改进。参考文献中所列内容对管理、准备和测试用户文档的过程提供了指南。注1: 过程中所涉及的文档管理者和其它的相关标准有:ISO/IEC 26514:2008 系统和软件工程 用户文档设计者和开发者的要求,ISO/IEC 26513:2009 系统与软件工程 用户文档测试者和评审者的要求和ISO/IEC 26512:2011 系统和软件工程 用户文档需方和供方的要求。本标准适用于用户文档编制项目的管理者的使用,适用于拥有信息设计和文档开发人员的组织。本标准也可供其他角色和对文档编制过程感兴趣的人员参考: 软件开发过程的管理者; 购买供方文档的用
12、户; 经验丰富的编写用户文档内容的人员; 创建电子版文档工具的开发人员; 研究使文档更加方便和易用的人因分析专家; 电子媒体方面的平面设计师; 共同设计文档在屏幕上展现形式的用户界面设计师和人体工程学专家。本标准也可用于管理以下类型的文档,尽管它并没有涵盖所有的方面: 用于帮助用户、培训和销售的文档和用于产品设计和开发的系统文档,这些文档是基于用户文档主题重用的; 非软件产品文档; 使用动画、视频和声音的多媒体销售演示; 正式培训课程中使用的基于计算机的培训(CBT computer-based training)资源文件包和特定的课程教材; 描述系统软件内部运作的维护文档。注2: ISO/I
13、EC 15289:2011提供了关于生存周期过程中的信息项(文档)更详细的内容。2 符合性2.1 符合性的定义项目或组织如果声称符合如下两个标准:ISO/IEC 15288:2008 系统和软件工程 系统生存周期过程,或ISO/IEC 12207:2008 系统和软件工程 软件生存周期过程,本标准可以用作符合性文档。本标准可以根据项目实际需求,从必要性和成本效益角度进行裁剪。裁剪可能是采取指定的方法,目的是符合某些标准规范,裁剪也可能是修改一些建议和方法,目的是更明确的反映软件和文档编制项目的特殊性。需方提出的裁剪决策宜在合同中明确说明。注: ISO/IEC 12207:2008的附录A(规范
14、性附录)描述了裁剪的过程。在本标准中,“应”(shall)一词用于表达具有约束力的规定,“宜”(should)一词用于表达一种尽可能的建议,“可以”(may)一词表明某些行为在本标准限定范围内是允许的。用户文档的部分内容(例如章节、主题、页、屏幕和窗口)使用了本标准中的术语,可以不要求声称符合性。2.2 符合性的场景软件用户文档管理的符合性针对不同情况有不同的解释。无论组织或者项目裁剪了所选择的软件生存周期过程还是全部采纳,都可以声称其信息管理和/或软件文档管理过程符合本标准。组织声称符合本标准时,应识别出一些相关联的情况,应发表一份关于裁剪的具体内容的公开声明。注1: 对于引用了“文档编制计
15、划”字样的段落,组织可以采用的一种处理方式是,对于任何特定的文档编制项目应在项目计划中对他们进行解释。 当项目声称符合本标准时,项目计划或者合同应明确记录对文档编制需求的裁剪。注2: 项目声称符合本标准时,通常也谈及到组织的标准符合性。 在一个多供方项目中:可能没有一个独立的合同能够描述所有需要的文档管理活动,因此每个独立的项目不能声称标准符合性。如果每一个需要的活动都由一个确定的团队完成,那么作为一个整体,项目可以声称标准符合性。项目计划应记录对需要任务的裁剪,对各方的任务分配,以及本标准中涉及到“合同”的段落的解释。 当各方(需方、供方,或者生产方)同意根据本标准由供方管理文档编制服务时,
16、本标准可能被包含在合同或者类似协议中。项目或组织也可将本标准作为内部标准,根据本标准管理文档编制服务。3 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。ISO/IEC 15288:2008 系统和软件工程 系统生存周期过程(Systems and software engineering - System life cycle processes)ISO/IEC 12207:2008 系统和软件工程 软件生存周期过程(Systems and software engine
17、ering-Software life cycle processes)ISO/IEC 24765:2010 系统和软件工程 词汇(Systems and software engineering - Vocabulary)4 术语和定义ISO/IEC 24765:2010中界定的以及下列术语和定义适用于本文件。注1: 本标准中的动词“包括(include)”表示,包括(1)给出了信息,或者(2)列出了信息的参考资料。注2: 本标准中的术语“文档”是指软件用户文档。本标准提到的“用户文档管理者”或“管理者”,适用于执行所需用户文档管理活动的任何人,忽略他们成本管理的头衔或责任。4.1受众 au
18、dience一类具有相同或相似特征和需求(例如,使用文档的原因、任务、教育水平、能力、培训和经验)的用户。ISO/IEC 26514:2008注:文档可能也有一些不同的受众(如管理人员、数据输入人员、维护人员),他们决定计划中的文档的内容、结构和使用。4.2完备 complete“文档”包含了受众需要的所有关键信息和其他任何必要的和相关的信息。4.3配置管理 configuration management包含配置标识、控制、状态报告和审核的技术和组织活动。ISO 10007:2003质量管理体系 配置管理指南4.4内容管理 content management通过元数据来控制信息单元,在文档
19、或信息项中,通过可变的结构和格式,进行选择性的重用。示例: 用户文档的内容管理,即帮助主题的管理,概念的解释,问题处理流程,依从性声明以及像软件产品名字和主机运行平台这样的变量,用于格式化输出中的元数据标签。4.5关键信息 critical information描述软件的安全使用、用软件创建的信息的安全性的信息,或对由软件创建或存储的个人敏感信息进行保护的信息。ISO/IEC 26514:20084.6顾客 customer供方提供的产品的接收者。注1:在合同上,顾客称为采购方。注2:顾客也可能是诸如最终顾客,用户,受益者或采购者。注3:顾客也可以是来自组织的内部或外部。GB/T 11457
20、-20064.7文档 document一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。在软件工程中 的例子,包括:项目计划、规格说明书、测试计划、用户手册。GB/T 11457-20064.8文档集 document set为了易于分发或使用,被划分为可单独识别的卷宗或文件的文档的集合。ISO/IEC 26514:20084.9文档汇集 documentation关于一给定主题的文档集合。GB/T 11457-20064.10插图 illustration与文本的主体部分分离的图形,通常会在主文本中被引用。注:在本标准中,术语“插图”用作表示表格、图形、展览、屏幕截图、流程图
21、、图表、绘画、图标以及其他类型的图形的通用术语。4.11信息设计 information design开发满足用户需求的文档内容的过程。4.12本地化 localization创建一个国家或指定区域的产品版本。注: 翻译过程和本地化过程可能是分开执行的。4.13最小化原则 minimalism精简文档的方法,只包含要完成文档所需的关键信息和最少数量的其他信息。4.14规程 procedure指明如何执行任务的一系列有序的步骤。4.15过程 process将输入转化为输出的一系列相互关联或是相互影响的活动。ISO/IEC 12207:2008,definition 3.174.16项目 proj
22、ect开发一个新产品或增强现有产品性能的一系列活动。ISO/IEC 12207:2008,ISO/IEC 15288:20084.17产品负责人 product authority对产品的功能和质量负全责的某个或某些人。4.18风险 risk事件发生的概率及其后果。ISO/IEC 16085:20064.19质量 quality产品、服务、系统、组件或者过程满足客户或者用户需要、期望或需求的能力。ISO/IEC/IEEE 24765:20104.20步骤 step规程中的一个元素(有编号的列项),用来告知用户执行一个(或多个)活动。 ISO/IEC 26514:2008注1: 软件的响应不被认
23、为是步骤;注2: 一个步骤可以包含一个或者多个动作。4.21策略 strategy组织的整体发展计划,描述如何有效的利用资源以支持组织即将开展的活动。ISO/IEC 38500:20084.22易用性 usability在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力。GB/T 16260.1:20064.23用户文档 user documentation描述、解释或指导如何使用软件的信息。 ISO/IEC 26514:2008注1: 印刷的用户手册、嵌入式屏显信息和帮助都是用户文档的实例注2: 用户文档需要包括解释或指导用户如何安装、实施、管理或作为最终用户操作软件的文档。4.
24、24工作分解结构 work breakdown structure(WBS)面向可交付物的任务层次分解,由项目团队执行,完成项目目标并创建出需要的可交付物。注: 工作分解结构组织和定义项目的整个范围。项目管理知识体系指南(PMBOK指南)-第四版5 生存周期过程中的用户文档管理5.1 软件生存周期中的用户文档管理ISO/IEC 12207:2008定义,用户文档管理是软件或系统生存周期中的支持过程。用户文档随着软件架构设计过程逐渐形成初级版本,在软件详细设计、软件构建,软件集成,软件测试和软件维护活动中根据要求进行更新。注1: 也可以是为先前发布的软件或者商业现货软件开发用户文档;注2: IS
25、O/IEC 26515 软件与系统工程 在敏捷环境下开发用户文档中有更多关于用户文档开发和软件开发之间关系的信息。无论用户文档开发是不是软件生存周期的一部分,文档都有自己的生存周期,包括一系列的过程实现阶段;设计和开发,生产和维护阶段。用户文档管理应应用于文档生存周期的其他活动中:a) 分析和设计,包括为项目文档设计做准备的;收集软件产品和用户的信息、任务和需求;基于这些需求设计文档;b) 开发和评审,包括根据适用性原则安排文档内容,通过编写文字和图形内容实施文档设计,在指定的媒体上实施信息,编辑和评审文档的内容,评估用户文档和产品的其他部分;c) 生产,包括文档的整合,编制,复制,包装和发布
26、;d) 维护,包括在软件产品的整个生存周期内,保持文档的准确性、控制文档版本,修改文档以提高其易用性。按照ISO/IEC 12207-2008的要求,用户文档管理者应执行符合ISO/IEC 12207:2008中6.3.6和7.2.1的信息管理和软件文档管理的过程。注3: 为了便于引用,附录B列出了这些过程的详细内容。用户文档管理者应参照PDCA(Plan-Do-Check-Act)理论,执行如下活动:1) 制定用户文档的策略和目标,准备文档管理计划;2) 规划用户文档项目;3) 监控用户文档项目;4) 选择和实现文档编制所需的资源、工具和支持系统;5) 改进信息管理和文档编制过程。成功实施信
27、息管理和软件文档管理可产生如下成果: 形成策略,以确定软件产品和服务生存周期中需要编制的文档; 确定软件文档开发过程中所采纳的标准; 确定过程或项目中编制的文档; 描述、评审和批准所有文档的内容和目的; 按照确定的标准,完成文档编制并确保其具有可用性; 按照确定的准则,维护文档。5.2 组合管理和内容管理上条是从单独产品的单个生存周期的角度来阐述软件用户文档管理过程的,例如一个单独的用户手册、帮助系统或者文档集。本条着眼讨论用户文档管理者管理多个项目和产品的情况。因此用户管理涉及如ISO/IEC 12207:2008中6.2.3所述的组合管理过程的运用:项目组合管理过程的目的是启动和维持必要的
28、,足够的,适合的一些项目,以满足组织的战略目标。这个过程需要投入足够的资金和资源,并批准创建所选项目的负责人,并不断地对项目进行资格验证,来对是否继续投资的决策做出解释。成功实施项目组合管理的成果如下: 商业机会,投资和必要性是合格的,有优先级的,有选择的; 每个项目的资源和预算是明确的,合理分配的; 项目管理的责任和授权是明确的; 项目满足协议和利益相关方的需求; 项目不满足协议和利益相关方的需求时,会被重新调整或取消。用户文档管理者应执行文档项目的组合计划,并与组织的整个组合计划保持一致。为了支持用户文档组合,并保持一致性,内容管理是一个有效的方法,创建和格式化有相似信息主题的多个文档时,
29、它可以避免重复性工作。内容管理分离了信息产品的内容和输出格式,从某种意义上说,内容管理是在信息资产上应用组合管理,而不是生产软件产品或用户文档。软件用户文档管理者应制定、实施和维护一个内容管理策略。内容管理策略应利用被管理的内容,指定有优先级的可重用内容的类型,以及有优先级的输出项(文档)的类型。内容管理策略可以定义内容管理过程和系统的责任和授权。可以识别潜在的利益相关者和内容使用者,包括本地化或者翻译的内容的使用者。可以建立标准用来判断哪些类型的内容需要被管理和维护。内容管理策略不指定任何特定的内容管理系统或者文档编写工具。注: 达尔文信息分类体系结构(The Darwin Informat
30、ion Typing Architecture (DITA)是一个创建和管理文档的规范,它建立了创作过程中的内容重用机制。5.3 信息管理战略和策略用户文档管理计划需要描述任务的关键信息:谁来做?使用哪些信息源?什么时候做?在哪里做?使用哪些工具?在管理者制定项目详细计划之前,需要一个信息管理策略:是否完成了所有要做的工作?是否每个方面都彻底地完成了? 管理者应建立一个信息管理或者用户软件文档管理策略。策略描述用户软件文档如何支持组织的目标以及服务客户,确定产品和服务的优先级。策略制定宜与用户文档利益相关者(那些对文档有效性感兴趣的独立个人或组织)进行协商,利益相关者可能包括高层管理人员,项目
31、负责人,客服人员,客户和业务分析人员。用户文档策略的一个重要理论是最小化原则。既然不能文档化每个软件产品的每一个细节,那么用户文档管理者就需要从策略性的角度,按重要性去支持用户,客户和生产组织的需求。最小化原则意味着用户文档宜包含关键信息和用户完成主要任务需要的信息。用户文档宜是面向任务的,而不是覆盖软件内部结构的每个细节。软件文档编制不宜将时间和工作集中在那些在软件界面就可以很容易发现和理解的软件功能上。按照最小化原则,用户文档没必要企图说明软件的每一个功能和每个可能的路径。用户文档宜是面向受众的。受众可能是经理,分析师,办公室人员,没有软件技能的专业人士,软件维护人员等等。由于工作任务的不
32、同,他们对文档有不同层次的细节和展式的要求。作为用户文档的信息管理策略的一部分,文档管理者宜计划信息重用和调整(内容管理)方案,以便有效和有效率地服务阅受众。所以文档计划宜说明为不同用户提供不同类型的信息。信息管理策略宜符合文档制定方针。文档制定方针由高层管理提供并支持,为所有决策者提供指导。方针提供广泛意义上的指导,不是详细的描述做什么和如何管理和编写文档。宜建立正式的、广泛公开推广的方针,并且与受方针影响的每个人进行沟通和协商。文档编写方针应确定采用哪个文档编写标准。相关信息的存储、记录管理、展示标准和约定需要与协议和规定保持一致。宜尽可能的采纳已有的标准,没有适合的标准时,宜编写标准和指
33、南。用户文档策略,方针和标准宜能够使管理者确定以下内容: 需要哪些文档类型; 提供多少个文档; 包含什么文档; 要达到什么样的质量水平; 文档什么时候完成编制; 如何存储、维护和传递文档。当信息管理策略已经建立,并且估算了组织资源和项目的花费和预期收益,用户文档管理者宜将策略应用到: 根据可用资源和限制,评估实现项目目标的可行性; 按重要性排序即将开始的项目。建立标准决定哪些项目需要执行。6 文档管理规划6.1 文档管理任务的WBS通过定义项目元素,项目WBS是有效的计划、评估和报告项目的基础。WBS宜被用来评估每个元素的时间和花费,也用来跟踪已用的时间和花费。完整的WBS是项目初始评估,持续
34、报告,纠偏,以及计算可能花费的一个参考框架。管理者应在发布的信息范围内,定义每个文档项目级别或者元素级别的WBS。WBS中文档元素的层数依赖于任务的范围和跟踪花费、进度和技术质量的详细程度。WBS中“元素”可以是: 文档类型,例如教材,参考资料和培训文档; 需要文档化的产品; 文档项目或者文档项目集; 发布的文档,例如用户手册,帮助系统; 文档的翻译版本或本地化版本; 文档元素(主题,章节,标题,插图)。通过WBS元素的进一步细分,可以确定适当的花费和任务类型。WBS元素需要的任务类型: 项目管理; 文档设计; 受众分析; 作为学科专家提供信息; 信息收集和研究; 写作; 编辑; 插图; 评审
35、; 修订; 易用性测试; 产品服务。为了与组织方针保持一致,工作任务也会包含基础设施的支持,他们被分配到几个WBS元素中,例如: 整个策略计划; 组织和项目的启动; 维护和管理一个内容管理系统和版本控制; 生产环境; 信息发布(例如通过物理拷贝或者互联网在线访问); 人力资源和技能开发。6.2 用户文档编写计划管理者应制定和维护用户文档编制计划,计划中包括: 确定用户文档管理和技术活动的范围; 确定项目的任务和交付物; 建立项目任务进度表; 确定完成信息管理和文档任务所需的资源。文档管理计划(第7章)包含进度表。根据正在进行的工作的复杂性和数量,每个文档都可能有一个独立的开发进度表,和软件产品
36、其他部分的进度保持一致,再合成一个总的计划。因为某些活动的复杂性,所以需要为用户文档测试、用户文档生产、本地化和翻译以及文档维护制定一个详细的计划和进度表。制定一个用户文档任务的进度表包括下面这些步骤: 识别和描述要发布的文档; 为文档编制工作定义WBS; 确定关键里程碑,截止日期和组织约束; 建立和WBS保持一致的主要任务; 确定任务和活动; 估算活动的持续时间; 建立任务和活动之间的依赖关系; 确定每个活动所需的资源; 检查资源是否过度消耗; 确定关键路径。确定活动的范围后,管理者宜通过检查那些执行和管理项目所需的资源(人,架构,工具和信息源)是否是可用的、充分的和适当的,以确保项目的可行
37、性。确定了文档进度的关键路径后(项目可能的最短工期),管理者可能需要在批准和执行的计划表之前对它进行修订。例如,作为利用相同资源的所有项目的主进度表的一部分,这个项目的进度表可能需要进行修改。如果文档必须比计划提早完成,可能要减少文档覆盖的范围或者增加一些任务需要的资源。文档进度表应包含评审,测试,修订和批准提交物的时间。文档计划应清晰的描述评审和批准提交物的责任人。注1: 管理者宜在任务的最后安排介绍性和概念性的主题任务,这样就可以应用在准备其它主题时积累软件和用户知识。文档计划和评估中宜包含的用户文档项目的典型任务可以分成如下几类: 确定目的和受众的相关任务; 设计任务; 开发任务; 翻译
38、和本地化任务; 生产任务; 变更管理和维护任务。注2: 这些任务各个方面的详细要求包含在标准ISO/IEC 26514:2008中。6.2.1到6.2.6列出基于这些标题的典型任务。6.2.1 确定目标和受众确定目标和受众的一些典型任务是: 获取软件和软件开发项目的目的和目标; 创建出版物项目的目的和目标; 进行受众研究-由软件或者文档开发者或者其他组织; 获取文档或者软件的客户说明; 计划和开展客户研究; 在用户的工作环境中和他们进行交流并观察他们的工作; 分析用户需要或想要执行的任务; 建立项目需求,包括项目的目标,动机和边界; 获取需要的资源; 获取需要的工具; 定位供方并进行协商; 学
39、习如何使用新的内容管理或者编辑工具和系统; 准备,评审和修订信息管理计划; 进行项目的管理评审,包括人员,进度,工作和花费; 评估项目的经验教训和过程改进活动。6.2.2 设计任务典型的设计任务如下: 收集软件信息(软件开发人员宜提供信息给文档编写者,并回答他们提出的问题); 评审现有信息主题的适用性并重用; 详细描述用户需要完成的任务; 熟悉软件(最好的途径是使用软件); 描述文档或文档集的结构; 编写文档内容说明书或者详细的、带注释的纲要; 设计文档格式和表现形式,或者选择和应用一种样式模板; 指定文档的编写和发布系统,也就是使用的媒体; 指定文档的接口设计; 重新设计满足用户需求的可发布
40、的信息; 转化现有的文档内容,变成一致的,可重用的主题; 评审和修订文档计划。6.2.3 开发任务典型的开发任务如下: 编写文字主题; 创建插图; 编辑文字内容; 建立电子文档系统; 提供特定的辅助特征; 管理工具、支持创作和内容管理的工具和系统; 提供版本控制; 评审文档的技术准确性; 评审电子文档的系统特性是否能正确操作; 评审插图的风格和质量; 进行最终版的编辑工作; 进行法律相关内容的评审; 识别关键字并生成索引和目录; 在每个计划的测试阶段测试文档,包括可用性测试; 在每个技术评审阶段,执行文档评审。6.2.4 翻译和本地化任务典型的翻译和本地化任务如下: 选择一个翻译和本地化服务供
41、应商; 准备目标语言的专业术语词典; 给翻译者提供源语言的文本和图形文件; 翻译或者本地化; 编辑和评审已经翻译的和本地化的文档版本; 更新翻译词典。6.2.5 生产任务典型的生产任务如下: 组合要发布的文件,主题或者章节; 准备用于发布的可印制副本或电子文件并打印输出; 检查打印质量; 检查数字媒体质量,例如DVD和CD等; 安排组装、发布和分发; 协调文档和产品的打包和运送。6.2.6 变更管理和维护任务典型的变更管理和维护任务有: 收集用户或者客服反馈的文档错误并分析这些事件报告; 由于软件变更或者文档错误而更新文档; 评审和重新测试变更后的文档; 维护文档和信息主题的版本控制; 根据组
42、织方针和安全性和私密性的要求,存档所有必要的项目资料; 根据组织方针和安全性和私密性的要求,处理所有不需要的,无效的,没有经过验证的信息。7 用户文档计划7.1 用户文档管理计划与文档编制计划本条主要讨论用户文档管理计划和用户文档编制计划的内容。尽管术语名称上很相似,但是在本标准中,两者是有区别的,主要是计划的范围和类型不同。文档管理计划覆盖一个组织执行信息管理过程的所有工作,很有可能是开发一个多用户多版本的文档产品。文档编制计划的范围会小一些,包括单独文档或文档套件的项目计划,通常也包含文档编写规范。本标准中,为了便于参考,每一个计划都要像一个单独发布的文档那样来描述。然而,如果计划是不发布
43、的,但是在版本库中作为参考资料,也应考虑一致性,这些计划被分割成独立的文档或卷,或者和其他信息项合成一个文档。计划标题和内容中的术语不需要与本标准一致。下面列出的文档(信息项)的内容列表并没有指定其标准的顺序、部分结构或者章节标题的列表。一些通用的内容应包含在计划中,动词“包含”在本文档中有两种含义,(1)给出了信息,或者(2)列出了信息的参考资料。一个计划应包含下面的元素: 发布日期和状态; 范围; 发行机构; 适用的政策、法律、标准、合同、要求和其他计划和程序的参考资料; 审批授权; 技术和管理评审和报告的方法; 其他计划,进一步补充计划细节而产生的计划或任务描述; 计划的活动和任务; 工
44、具,方法和技术的确定; 进度表; 预算和成本估计; 资源以及资源分配; 职责和授权,包括高级责任人和直接责任人; 各方之间的沟通接口; 风险和风险识别、评估和转移活动; 质量保证和控制测量; 环境、基础设施、保密性和安全性; 变更流程和变更历史; 终止过程。7.2 文档管理计划的内容管理者应制定一份文档管理(或信息管理)计划,计划中定义和描述信息内容管理和文档编写的过程。文档管理计划展现了生存周期中,一个组织打算如何实施信息管理或者软件用户文档管理的活动。除了7.1中确定的通用内容,文档管理计划还宜包含如下信息: 信息管理策略以及和整体组织战略的关系; 描述用户所需的电子版和打印版信息的授权、开发、评审、存储、通信和维护的过程和相关活动; 确定信息获取,重用和生产的过程; 与整个组织方针相一致的资源,角色和责任; 内容管理或重用策略与版本控制(文档配置管理); 确定用户电子版或打印版文档的结构、格式和风格的标准、指南、模型或模板; 方法和工具; 文档开发过程中实施的质量控制; 确定信息开发、评审和批准过程中典型的进度表和标准的持续时间; 确定用户文档