系统与软件工程用户文档的管理者要求.docx

《系统与软件工程用户文档的管理者要求.docx》由会员分享，可在线阅读，更多相关《系统与软件工程用户文档的管理者要求.docx（26页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、系统与软件工程用户文档的管理者要求1范围本标准支持软件用户对文档一致性、完备性、准确性和可用性的要求。它为文档管理者提供策略、 策划、执行和控制。它指明贯通整个软件生存周期的用户文档管理过程。它也包括用户文档管理的关键 过程，即文档编制计划和文档管理计划。本标准提供了软件文档编制和用于文档编制的信息管理过程的概述。同时还描述了用于文档编制的 组合计划和内容管理。具体来说，它专注于以下内容：项目启动时的管理要求，包括建立过程和规范，建立基础设施，建立团队并列举用户文档团队 所需要的角色；文档管理控制所需的测量和估算；对用户文档编制工作进行管理控制；支持过程的运用，例如变更管理，进度和成本控制，资

2、源管理，质量管理和过程改进。参考文献中所列内容对管理、准备和测试用户文档的过程提供了指南。注1：过程中所涉及的文档管理者和其他的相关标准有：ISO/IEC 26514： 2022系统和软件工程 对用户文档设计 者和开辟者的要求（IEEE标准26514-2022,采用IS0/IEC 26514:2022的IEEE标准，系统和软件工程对 用户文档设计者和开辟者的要求），1SO/IEC 26513： 2022系统与软件工程对用户文档测试者和评审者的 要求（IEEE标准26513-2022,采用IS0/IEC 26513:2022的IEEE标准，系统与软件工程 对用户文档测试 者和评审者的要求）和IS

3、O/IEC/IEEE 26512： 2022系统和软件工程对用户文档需方和供方的要求。本标准合用于用户文档编制项目的管理者的使用，合用于拥有信息设计和文档开辟人员的组织。本 标准也可供其他角色和对文档编制过程感兴趣的人员参考：软件开辟过程的管理者；购买供方文档的用户；经验丰富的编写用户文档内容的人员；创建电子版文档工具的开辟人员；研究使文档更加方便和易用的人因分析专家；电子媒体方面的平面设计师；共同设计文档在屏幕上展现形式的用户界面设计师和人体工程学专家。本标准也可用于管理以下类型的文档，尽管它并没有涵盖所有的方面：用于匡助用户、培训和销售的文档和用于产品设计和开辟的系统文档，这些文档是基于用

4、户文 档主题重用的；非软件产品文档；使用动画、视频和声音的多媒体销售演示；正式培训课程中使用的基于计算机的培训（CBT computer-based training）资源文件包和特 定的课程教材；描述系统软件内部运作的维护文档。注2： ISO/IEC/IEEE 15289： 2022提供了关于生存周期过程中的信息项（文档）更详细的内容。2符合性符合性定义项目或者组织如果声称符合如下两个标准：TSO/IEC 15288： 2022系统和软件工程 系统生存周 期过程，或者ISO/IEC 12207： 2022系统和软件工程软件生存周期过程，本标准可以用作符 合性文档。写作规范；图表样式；警告，提

5、醒和注释的表示形式。规范可以说明数据元或者分类的使用。ISO/IEC 26514-2022包含用户文档表现格式和样式的详细要求和指导。基础设施管理者应配备相应的基础设施资源或者服务，用于信息的创建，变更，展示，评审和协作，查找， 检索，传递和发布。信息的存储和保留应易于获取和读写，防止受破坏，恶意修改和丢失。信息的存储介质，位置和保护宜根据指定的存储和检索周期，组织的方针策略，协议条款和立法来决定。文档管理计划应指明需要的基础设施系统（硬件设备和软件）。信息开辟团队6.1.1 角色定义管理者应定义好一系列计划要执行的用户文档活动需要的角色，例如信息和文档的设计、开辟和生 产活动。管理者应确定每

6、一个角色的职责、技能和专业知识。有两种安排角色执行任务的方式：职能型：一个文档团队负责一个或者多个正在持续开辟的软件产品的文档编制工作；项目型：文档团队成员被分派到项目团队中，完成其文档编制工作，直到项目结束。角色不是单单一项工作，根据任务的大小，可能一个人担任多个角色，也可能多人担任一个角色。 一个小规模的文档编制项目，一个人可能承担所有必要的角色，但可能不需要所有的角色。一些大规模 的项目，可能涉及多人担当一个角色，而且需要所有的角色。非常大规模的项目可能还需要额外的支持 角色（例如，人力资源专家，行政管理支持和IT支持）以确保团队顺利的完成任务。注1： IS0/IEC 26515描述了一

7、个敏捷开辟团队需要的用户文档角色。组织应将完成项目所需要的资源进行分配。组织应确保具备所需技能和专业知识的人充当这些角色。一些角色可以分配给和文档开辟有关的人 员，但是他们不属于文档编制团队，不需要向文档编制团队汇报工作。示例：提供产品信息的领域问题专家（SME subject-matter export）或者检查关键功能正确性和覆盖率的技术评 审人员，他们都不属于用户文档编制团队。用户文档团队的成员最好能熟悉相关学科知识、业务或者软件所需支持的功能和承担的任务，这些 有助于他们准确的表达软件的概念和功能，匡助软件使用者完成任务。但是，信息设计人员或者编写人 员也没有必要成为领域问题专家（SM

8、E）。同样地，信息开辟团队的成员只需要在工作中能够使用基础设施工具即可，管理者没有必要要求团 队成员在某个指定工具上具有丰富的经验。编写者学习一个新工具和技术的能力比他在某个特定工具的 丰富经验的能力更有价值。同样道理，编写者能够快速学习新工具，也就能快速理解新软件并将其文档 化。注2：当用户文档服务对象是一个短期项目或者紧急任务时，选择对特定工具比较熟悉的团队成员是比较适合的。用户文档团队成员的能力和责任可以分为三个级别，初级，中级和高级。下面有关编写者职责水平 的描述可能同样适合其他角色。初级编写者在全面指导下进行工作。工作内容涉及写作技能和原则的运用，需要一定的主动性和判 断。这个水平的

9、人员经过相关培训，有良好的沟通技巧。但是缺乏或者没有信息技术方面的实际工作经验。 随着工作经验的积累，对他们的审查和指导逐渐减少，而是希翼他们能够更多的发挥主动性，独立的判 断和思量。这个水平的人员可能需要和辅助人员互动并给他们提供工作指导。编写者或者中级编写者，在有限的指导下完成编写和相关活动。这个水平的人员应该经过相关培 训，能够胜任广泛的技术文档编写工作，具有丰富的经验。根据项目的大小和复杂性，他们可以作为个 人，也可以作为团队中的一员，或者团队的领导者来完成工作。高级编写者在有限的指导下，承担技术性文档编写任务，需要具有相当大的原创性，独立性，主动 性和判断能力。这个水平的人员应该已经

10、熟练掌握信息开辟的技术和原理，并在多个项目中成功运用。他们宜在时间，预算和形式限制下展示他们监控，控制和评估变更以及创新的能力。他们的工作包括指 导文档的开辟、修改和维护。工作描述可以基于角色列表和对应的技能水平。管理者可以协助编制工作描述。管理者宜就需要的 角色及拥有的技能与负责招聘的人员进行沟通。6.1.2 用户文档编制的角色示例一个指定团队所需要的角色根据团队要执行的任务而定。组织中的不少角色都需要具备一定的责任和能力，例如：能够与产品开辟者，教学设计者，技术支持人员，培训人员和其他相关人员高效的合作；接受并热中于对传统工作方式的改变。接下来的内容中定义了每一个角色的职责。管理者宜确定组

11、织和项目需要的角色，确保团队每一个 操作的方方面面都被覆盖到。6. 1.2. 1 管理者管理者的职责包括： 确定每一个文档项目和任务的范围并对所需工作进行估算； 制定计划，并在整个信息开辟生存周期中执行计划；安排任务；选择员工并将任务分派给员工； 测量和监控项目发展情况，对变更实施控制； 向利益相关方（包括管理层）汇报项目发展情况；管理风险； 解决团队成员之间以及和其他团队成员之间发生的问题； 指导和支持团队成员，与所有利益相关方进行互动沟通，发挥高水平的人际沟通技能； 与信息架构师和设计师沟通，平衡需求和成本。对文档进行管理需要了解文档开辟过程中涉及的任务。即使是在文档维护过程中，项目管理技

12、能也是必要的。团队领导者团队领导者的职责包括：指导编写者和插图设计者，确保他们按照进度和需求进行工作，发挥高水平的人际沟通技能； 向管理者不断地提供项目监控信息。信息架构师信息架构师的职责包括：采集组织需求，用户需求，预算和其他作为项目输入的信息；制定文档编写策略，例如采用最小化原则；计划和记录不同受众所需的信息，形成需要编制的信息文档集； 同文档编制团队（特殊是信息设计师）和组织其他成员沟通文档编制策略，发挥高水平的人际 沟通技能；根据业务需求和相关约束，发布较好的信息设计；与管理者协作，平衡需求和成本。可用性设计师可用性设计师的职责包括： 与信息架构师和信息设计师协作，确保计划编制的文档具

13、有可用性； 安排和分析文档及相关产品的可用性测试，应用可用性的理论和实践知识； 分析文档与相关产品是否符合健康和安全性方面的法规、原理和实践。 . 1.2. 5平面设计师平面设计师的职责包括：设计文档的整体外观和感觉；设计开辟文档模板，包括封面设计，需要时可以借助文档工具；与插图设计者协作，确保符合图形设计标准；需要时，可借助图形设计工具制作文档中需要的图形元素。6. 1.2. 6信息设计师信息设计师的主要职责包括：进行文档受众分析；为独立文档和文档集开辟文档计划；将组织文档编制策略应用到信息设计中；与管理者协作平衡需求和成本；和文档编制团队成员沟通信息设计；监控文档编制工作，确保其按计划执行

14、。6. 1.2. 7编写者编写者的主要职责包括：与领域问题专家交流，理解将要被文档化的资料信息；根据文档计划中指定的结构编写文档；根据编写规范，高水平的发挥书面语言表达技能；与插图设计者协作完成图形制作；与评审人员和领域问题专家协作，识别一些不清晰的地方和错误；在履行这些职责时，发挥高水平的人际沟通能力；凭借文档编写和文本处理工具的背景知识，培养熟练使用指定的内容管理工具的技能。插图设计者插图设计者主要职责包括：运用高水平的图形技能和图形工具进行图形开辟；凭借常规图形设计工具的背景知识，培养熟练使用指定的图形开辟工具的技能；与平面设计师沟通图形开辟标准；与编写者沟通图形内容。6. 校订者校订者

15、的职责包括：根据文档计划检查和修订用户文档初稿，改善文本和插图的布局、清晰性、简洁性，完整性和 可用性；检查文档初稿是否符合使用的国际标准、国家标准或者组织内部标准；检查和纠正文档编写风格上的错误和不一致性，运用高水平的书面语言表达能力改善文档。可以在各个级别进行修订，从初稿的重构和重组到信息或者语法错误。修订的水平宜与用户文档的重要性一致。6.1.2.10 质量专家质量专家的职责是：制定文档开辟过程，供文档开辟团队成员使用；评估文档是否符合相关规定；审查文档开辟过程，确保其符合内部和外部标准。6.1.2.11 索引编制者索引编制者的职责包括：编制索弓I （包括纸质版和电子版索引），运用经验和

16、技术选择索引关键字和内容；使用索引生成工具制作索引，必要时加深对工具的了解。6. 1.2. 12测试人员测试人员的职责包括：评估文档中信息的准确性；评估文档的可用性；在文档可用性和精确性方面，提供适当的修改意见。用户文档测试人员可以提供一些文档和软件的修改建议。翻译或者本地化工作协调员本地化协调员的职责包括：与翻译或者本地化服务供应商沟通，向其提供翻译或者本地化的资料，维护版本控制；提供一个术语列表，或者提供以前翻译过的术语和不需要翻译的术语，比如产品名称就是不需 要翻译的术语；确保翻译的质量；参预制定合同框架，约束翻译供应商的服务质量；评估供方是否符合合同在技术方面的要求。这个角色可以获得采

17、购部门的支持。ISO/IEC/IEEE 26512-2022描述了获取和提供用户文档服务的要求，包括翻 译和本地化服务。6. 1.2. 14翻译人员翻译人员的职责包括：翻译文档，运用高水平的语言技能（包括源语言和目标语言）和翻译人员的专业技能；制定一份翻译词典；测试和评估翻译后的资料。发行人员发行人员（或者发行协调员）的职责包括：构建各种介质的文档的最终版本，并提供给客户，需要时通过工具自动化完成；监督发布前的最后质量检查；确定文档的封面和封底，并添加到打印的文档上；确定元数据，并添加到电子文档上；与软件开辟者联系，将需要的嵌入式文档集成到软件产品中；生产交付物介质，例如磁盘；实施发行资料的版

18、本控制。6. 1.2. 16印刷协调员印刷协调员的职责包括：与内部或者外部印刷供应商联系，利用印刷行业目前印刷技术和过程的经验和知识；确保样品和最终印刷品的质量，成本和及时交付；参预制定合约，约束印刷服务，评估供应商的服务是否遵循合同条款（除非采购部门或者内部 印刷机构提供服务）。7用户文档管理控制方法文档编制测量在对文档进行正确的估算、计划和安排的过程中，文档的测量起着很重要的作用，文档测量还可以 控制和改进文档的产品和过程。采集和分析文档的测量能匡助我们理解用户文档的质量水平、提高其质 量并对质量的改进进行量化。通过测量质量，文档管理者可以：了解质量水平是否正在改变；传授高质量技术（”成功

19、的案例”）；确定竞争者（“竞争分析”测量的过程使用“Plan-Do-Check-Act”模型。文档管理者应计划如何测量文档，使用的方法是确 定测量的目标并定义要采集的关键测量。文档管理者应选取那些利益相关方认为重要的测量，进行文档 化，并考虑如何将其进行改进。管理者应采集、记录和分析测量，建立基线并确定其发展趋势。管理者 应用测量控制工作质量并进行工作改进。文档和信息管理的测量应实用。实用的测量有下列特点：定义明确，使得每一个人对其有一致的理解；具有一定的范围、故意义的值域和已知的斜率，也就是说测量结果的曲线形状是可以理解的；可以容易获得或者值得获得；可以再现或者重复；能够测量过程的结果和质量

20、的重要指标。示例：对于每1000个文字的书写错误，其范围可能是0 （没有错误）到1000 （每一个文字都是错的）里可能的取值， 值域是整个范围，斜率是负数（数值越小越好）。测量是客观的、可以重复的，测量的对象是由权威机构指定的文字列表。IS0/IEC 15939-2022给出了更详细的信息。7.1.1 用户文档产品测量管理者对用户文档测量最常见的需求是能够估算文档的大小和编制文档所需的时间和资源。传统上 用页数来测量用户文档的大小，会因文档的发布格式和每页内容量的不同而有很大的变化。现在，主题 数常被用来确定最后产品的大小，因为主题数是由被文档化的用户任务的数量来决定的。为了估算，机 构宜建立

21、一个主题的典型长度（像在线匡助系统那样）。在确定一个软件用户文档所含主题数时，宜考虑下列几个复杂因素：软件对机构战略上的重要性和软件功能的关键性，保持文档的最小化原则；在用户文档项目和软件产品中，重用或者分享主题的可利用性；产生或者重新产生的用屏幕截图作为插图的插图数量；从受众的角度来看，文档化的操作过程（工序）可能是相对复杂的或者简单的。相对复杂的操作过程（工序）可能需要几个主题才干被覆盖到；受众对软件功能中的概念和自动化的工作流的理解程度；受众对软件的基本导航技术的熟悉程度；对参考资料的需求程度，例如常见错误处理流程、错误信息以及没有内置在软件中的命令和代 码的列表。软件内部函数的复杂性和

22、数量同用户手册中需要的主题数没有很大的关系。源文档的文字数量是评估翻译成本的一个常用测量指标（翻译后的语言的文字数量会发生变化）。 对文档修订的翻译，修改的文字数量是一个常用的测量指标。间接的产品测量，可以评估可用性的特征，例如每一个主题索引术语的个数、每一个主题示例个数。7.1.2 用户文档生产率的测量估算文档的生产率对计划和控制文档是很重要的，然而，传统的每页小时数（或者最近使用的每主 题小时数）的测量受到许多不确定因素的影响： 产品的简洁性很重要，像快速参考卡，其需要特定的设计，比编制一个长文档需要更多的时间； 与要编写的文字数量相比，需要捕获或者开辟的插图的数量； 文档化信息的复杂度、

23、编写人员的技能、对素材和软件的熟悉程度； 可利用的领域问题专家、软件需求、软件系统； 重用或者自动更新的内容的比例，例如文档中使用变量改变产品名称； 由于软件需求变更和文档化的软件功能的变更造成返工所产生的时间损失； 包含在文档估算中的间接工作。例如内容管理系统和模板的建立和项目领导者（特殊是敏捷开 发团队）的参预、SME的访问、软件测试和用户文档可用性测试。管理者应制定基线生产率测量以及记录后续项目的生产率。管理者宜权衡这些不确定因素的影响， 估算生产率和新增任务导致的项目周期变化。通过比较软件开辟者或者工程师的数量，组织时常会尝试去估算所需要的用户文档资源，这些估算 方 法是自顶向下的并且

24、是有参数的。因为本条中所列的这些不确定因素，这种估算往往有1： 5到1： 100的不同，而且机构间是不能进行比较的。当用户文档人员更多地参预到软件开辟团队的工作中以 及支持一个重要的新产品的时候，就需要更多的用户文档人员。而维护更新充分文档化的产品则需要 较少的用户文档人员。用户文档人员与软件开辟人员的比例或者修订者和编写者的比例可以用作机构 内部的估 算，但是要基于对相似产品的经验并根据项目的复杂性和人员的经验做调整。 . 1.3用户文档质量测量用户文档的质量特性包括：技术准确性；易于查找到所需要的信息，其中不会混杂不需要的信息；易于理解文档内容；有效地使用插图和示例；易于使用的设计、包装或

25、者介质；易读的文字；语法的正确性；对独立解决问题的实用程度。为了测量这些特征，传统上用户文档的质量测量需要跟踪缺陷的数量，例如语法或者拼写错误或者 软件和用户文档间的差异。合理的质量测量与标准和要求一致，这些要求包括内容、结构和格式，并 且假设用户文档要求存在于文档计划之中。这些测量影响用户对文档的可靠性和质量的印象。可以用 检测列表来评估一致性。然而，最合理的用户文档质量的测量是可用性测试的结果。管理者应确保文档被测试以符合其可用 性要求（7.3）。生产完成后，用户文档质量可以通过分析组织服务平台的电话来测量。管理者宜通过分析服务电话 来确定用户文档和客服人员的文档的哪些部份需要增加、纠正和

26、改进。文档的修订可以通过在线的形式 发布给用户，也可以通过更新客服人员的知识主题和过程。改进用户文档可以大幅度地减少服务台电话 的数量和持续时间，因此降低软件支持费用并且提高顾客对软件和组织的满意度。通过对分析报告的问 题，也可以改进未来项目的文档计划和其他过程。用户满意度调查也可用作估计用户文档的质量并作为改进建议。过程改进测量管理者宜确定、记录和分析信息管理和用户文档管理过程的测量来改进过程。典型的测量值包括：文档策略和程序或者操作指令所覆盖工作的比例；完成操作步骤所用的平均时间长度；增加顾客价值所用操作步骤的比例；直接应用到一个项目与间接应用到多个项目所需小时数的比值，称为开消；满足质量

27、标准或者符合标准系统、格式、风格和计划所需返工的工作量；按时或者按预算完成的项目的百分比。文档估算管理者应记录资源估算的依据以及记录某项目所需资源的计算结果，并与实际值进行比较来改进以 后的估算工作。估算开辟文档所需的时间和资源宜用自顶向下和自底向上相结合的离散估算法来进行，两种方法都 需要至少知道初步的文档计划或者WBS。自顶向下的估算法比较本项目与其他相似项目。例如为一个系列的打印机编写用户手册时，可以根 据打印机产品线的前四个型号文档编制工作中的内容重用量和工作减少量，来估算该系列第五个型号打 印机文档编制工作所需的工作量。在一个新工作中使用自顶向下估算法时，可以和以前的工作进行比较，需

28、要根据项目的大小和复杂 度以及资源的可利用程度和水平进行调整。自底向上估算法根据每一个具体任务的估算计算出总的估算。估算宜与机构的基准生产率测量相 比较，例如与每主题的小时数或者每插图的天数相比较。当项目的预算不多时，管理者宜决定所分配的预算是根据自顶向下的方法还是根据自底向上的方法 估算出来的，其差距可导致文档项目范围的缩小。相似地，当项目提交的截止日期一定时，管理者宜根 据估算和初步进度决定提交日期是否可行。管理者可能需要修订估算以利用附加的或者更多的经验丰富 的资源，如果资源有限，修订可能使项目的花费更大或者使项目的范围缩小。执行一个试验项目是估算未知项目比较好的方法。编写者宜开辟一个样

29、本章条或者较少的主题，并 记 录所用的时间，管理者可将实际所用时间值作为基准来得到项目其余部份的估算值。除了估算执行任务所需的资源（如6.2所列）,文档管理者宜考虑外包服务所需的成本，例如翻译、 生产和复制、材料、设备、包装和运输。当估算生产已打印文档副本的成本时，管理者宜做如下考虑；文档的页数；页面的大小；使用的颜色；特殊插图的准备；纸张的质量和类型；每一个文档需要复制的数量；打印成本；装订和包装的成本，包括材料；发布成本。8管理控制在文档中的应用目的和成果管理者应对信息管理和软件用户文档的编制工作进行控制，以确保其符合计划和进度、保持在项目 的预算内、满足质量和可用性的目标。控制包括：执行

30、测量；记录、调查并解决问题；采取行动以避免问题再现；估计请求的变更所产生的影响；调整行动方向以更正或者减少目标和计划的偏离。管理者应在项目重要的里程碑或者至少每一个月定期地进行评审并准备发展分析报告。像用户文档 和相关组织的策稍不断要求的那样，管理者应定期地对整体工作进行评审以确保所有的工作都是可行 的。对于如果继续投资，其缺点或者风险超过其利益的项目，组织在合同允许的范围内，应将其取销 或者暂停。变更管理管理者在软件产品和文档的生存周期内，应有计划地控制计划、记录、提交的文档和主题的重用和 修订。变更管理计划宜描述如下内容：控制信息的修订；对电子版和纸质版的文档进行存档；控制和发布正式批准的

31、文档管理计划。管理者应为可惟一标识的信息项和文档建立一个变更系统，使其接受变更控制。标识的数据宜包括 文档化的软件产品、语言、用户文档类型、版本和修订、发布的日期和状态（如初始状态或者最终状态）。按照组织对记录的存储、安全性、维护和备份的需求，重要的资料应被保存。进度和成本控制管理者应跟踪进度和资源计划或者预算的执行情况。跟踪执行情况包括记录实际持续时间、实际使 用的资源、进度表中文档每一个部份以及WBS元素或者任务的完成情况。对于某些已经开始但尚未完成的主题，可以用变化的百分比来表示进度。更加严格的跟踪方法在开 始任务时指定固定的百分比（例如任务已完成20%还剩80%未完成、甚至任务已完成0

32、还剩100%未完成）。当跟踪结果显示一个项目进度落后时，不宜为节省时间而删除进度中那些能够确保质量的活动，如 内容评审和可用性测试。管理者宜权衡费用、进度和质量之间的影响。管理者通过比较项目的状态和基线的进度表与预算，掌握项目的活动是提前还是落后，是低于预算 还是超出预算。然而，这些进度或者费用的变化不能反映项目执行的整体情况。普通情况下，人们都期望低于预算，但如果花费比预算少是因为团队完成的工作量不足而落后于进 度表，那这个项目可能不会完成既定目标。相反地，如果项目的花费高于预算但团队完成的工作比计划 快不少，那末团队可能实际上会提前完成任务，且从总体上来讲不会超出预算。可以用实现价值或者预

33、算的已完成工作量成本来更好地对执行情况进行测量。如果执行情况正常， 实现价值将等于实际已完成工作量成本。实现价值大于实际已完成工作量成本表明项目的执行情况是 令人 满意的，实现价值小于已完成工作量成本表明项目的执行情况令人不满意的。示例：一个管理者估计第一章可以在10个工作日内完成，每一个工作日的花费是500元人民币（总共5000元人民币）。 第6天结束时，这个管理者根据已完成的材料估算出这一章已经完成为了 80%,按计划宜用8天来完成（10天x 80%） o 实现价值是5000的80% = 4000元人民币，实际费用为3000元人民币（6天，每天500元人民币），实现价值大于实际 费用，结果

34、表明项目的执行情况是令人满意的。资源管理 . 1. 1项目沟通一致性和团队成员间的及时沟通是非常实用的，可以对策略、目标和计划进行沟通，也可以评估风 险、获取项目情况、报告问题解决方案。有些机构内部存在一些限制，例如（虚拟的）项目组成员的地 理位置相距很远，这时电子通信媒体就显得很重要。8.1.2 管理文档团队成员和供方管理者应根据项目中确认的角色（示例见8. 3. 2）,确定知识和技能的水平以达到他们满意的表现。 组织应雇用或者选拔和培训员工以满足组织和项目的资源需求，或者获取用户文档服务。管理者应就信 息管 理部门职员的角色和责任的描述与他们进行沟通。管理者应保留所有员工表现的记录，作为以

35、后 项目估 算和个人工作分配的依据。IS0/IEC/IEEEE 26512-2022,系统和软件工程-用户文档需方和供方的要求，处理用户文档服务的供方的管 理控制。8.1.3 管理翻译服务翻译管理是需要平衡用户文档的准确性、时间要求和费用的一个特例。通过在项目一开始就对翻译 有所计划，管理者可以用下面的方法来节约成本并提高翻译的质量：选择采用根据图表表示的而不是根据文字表示的文档设计，并且避免插图中的文字标签转换成 图形图象；选择合适的输出格式，当翻译后的文字量比源文字量大时，有足够的空间（例如，将中文翻译 成英文）；特殊注意那些和源语言的阅读方向不同的语言输出格式（例如，将英语翻译成阿拉伯语

36、）；使用限定的词汇，以保持术语和语句结构的一致性；通过翻译服务，使得翻译词典可以重用；对材料的重用进行计划，从而仅对变化的词汇进行翻译；为了避免重复劳动，当源语言的版本彻底通过评审和测试后再安排翻译工作。在翻译项目中，为了使项目按时竣工，需要对翻译、评审、测试和修订或者改正进行严格监视和控制, 并进行额外的管理。质量管理管理者宜决定怎样取得和保持质量，和文档策略保持一致。示例：用户手册可以是有几页纸装订的纸质版或者电子版的，也可以包括由图表专家设计的插图，或者是可以在电 子设备上播放的视频。管理者宜根据信息的重要程度和文档的用途建立内容、结构和版面的标准（例如：是时常使用的参 考资料还是初级培

37、训教程），标准可以包含在文档管理计划、文档计划、模板或者模型中。高质量的用 户手册是：准确的；关键信息是完整的；清晰的；高效的，根据用户快速找到所需信息的能力来衡量；有效的，根据用户应用相关信息完成一项任务的能力来衡量；和用户需要相关的，提供满意的用户体验。1 .1.4管理产品质量一一评审和测试管理者应在用户文档交付前确保其满足需求。用户文档典型的质量问题是不正确、不完整、含有不 必要的信息、使用不一致的术语、没有条理、难度相对于目标用户来讲过高、访问方式或者导航不明确、 对指导性的资料来讲不是面向任务的。1S0/1EC 26513-2022系统和软件工程用户文档的测试者和评审者的要求，有详细

38、的要求，确保产品质量通过 评审和可用性测试。IS0/IEC 26514-2022系统和软件工程用户文档设计者和开辟者的要求，描述了怎样对用 户文档进行结构化，以指导用户使用软件。IS0/IEC 9003-2004系统和软件工程 计算机软件在ISO 9001-2000 中的应用指南，可以作为软件用户文档质量的参考。8 . 1.5风险和问题管理用户文档的风险可以影响一个用户文档项目或者组织内部一组文档的内部进度、费用和质量。基于 组 织的信息管理策略和项目的目标，用户文档管理者宜识别、评估、处理和监控风险。风险处理的措 施包 括避免、优化、转移或者保留（接受）风险。风险避免-选择不同的方法来消除风

39、险；风险转移-采取一些步骤降低风险的严重程度；风险接受-判定避免或者转移风险所需的费用大于如果风险转变成实际问题可能带来的影响。注1：关于风险的讨论详见ISO/TEC 16085-2022系统和软件工程生存周期过程风险管理。除了管理文档项目的风险，文档管理者还宜注意到因为软件用户而引起的风险，还宜注意到可以减 少这些风险的方法，例如：通过包含警告和注意。管理者应建立和实现用户文档的问题管理系统，建立和实现一个程序来发现和评审用户文档报告的 问题、为问题的严重性划分等级、确定问题的根本原因、解决问题以及当需要时修正组织的过程。注2：当软件和用户文档同时开辟时，一套综合的问题管理系统可以同时解决两

40、方面的内容。过程改进当组织具有可重复的文档化过程时，有可能对其进行改进。管理者应在项目结束时召开评审会议， 采集成功过程的信息和过程改进意见。管理者应确保对这些改进意见进行记录和评审，并且使其得到实 施。AA目次根据需要进行调整A. 1叙言本文档编写计划由ABC公司文档管理者提供（插入日期）。状态：草稿第一版。本文档编写计划已获得*批准。A.2引言提供一个文档项目的简要说明：目的，范围，发行机构，审批机构。本文档计划仅针对XYZ软件产品用户的需求，包括销售商、采购商和产品最终用户。文档管理计划中描述的文档旨在产生一些经济效益和益处，包括改变企业文化，降低成本，更好的 定义流程，获取更多的软件投

41、资回报，有益于知识的有形化存档，更快更有效的指导新员工入职，遵循 标准和相关法规。A.3文档集概述确定文档集中各个独立项的标题，对其关注的重点进行一个简要描述。文档将被划分为如下几卷： 经销商手册； 安装手册； 客服人员手册。经销商手册主要针对产品销售人员，向他们介绍产品，列出产品的主要功能，以及给用户带来的益 处。安装手册；客户服务手册；此文档还包括对用户使用特殊硬件时的操作指导。A.4项目和软件产品背景描述受众中每类成员的使用环境以及这些用户特点对文档设计和展示的影响。对于嵌入式文档，将指定软件运行环境，每种类型介质的导航元素，包括任何限制规则。建议说明 规则的根据，有利于匡助用户理解和使

42、用规则。ABC公司利用两年时间开辟了创新性的银行软件产品XYZ。文档管理者为XYZ开辟了文档编写计划。 销售商销售XYZ,文档编写计划包含了详细的文档，用于向销售者介绍产品。培训部门将为XYZ开辟培训模块，文档团队将密切合作，确保文档的兼容性。XYZ将提供批处理模式和交互模式，从周一到周五，700用户使用系统，XYZ发布几个月后，一些相 关产品也将发布。A. 5用户对象本标准可以根据项目实际需求，从必要性和成本效益角度进行裁剪。裁剪可能是采取指定的方法， 目的是符合某些标准规范，裁剪也可能是修改一些建议和方法，目的是更明确的反映软件和文档编制项 目的特殊性。需方提出的裁剪决策宜在合同中明确说明

43、。ISO/IEC 12207： 2022的附录A （规范性附录）描述了裁剪的过程。在本标准中，“应”（shall）一词用于表达具有约束力的规定，“宜”（should）一词用于表达 一种尽可能的建议，“可以（may） 一词表明某些行为在本标准限定范围内是允许的。用户文档的部份内容（例如章条、主题、页、屏幕和窗口）使用了本标准中的术语，可以不要求声 称符合性。符合性场景软件用户文档管理的符合性针对不同情况有不同的解释。无论组织或者项目裁剪了所选择的软件生 存周期过程还是全部采用，都可以声称其信息管理和/或者软件文档管理过程符合本标准。组织声称符合本标准时，应识别出一些相关联的情况，应发表一份关于裁

44、剪的具体内容的公开声明。注1：对于引用了 “文档编制计划”字样的段落，组织可以采用的一种处理方式是，对于任何特定的文档编制项目 应在项目计划中对他们进行解释。当项目声称符合本标准时，项目计划或者合同应明确记录对文档编制需求的裁剪。注2：项目声称符合本标准时，通常也谈及到组织的标准符合性。在一个多供方项目中：可能没有一个独立的合同能够描述所有需要的文档管理活动，因此每一 个独立的项目不能声称标准符合性。如果每一个需要的活动都由一个确定的团队完成，那末 作为一个整体，项目可以声称标准符合性。项目计划应记录对需要任务的裁剪，对各方的任务 分配，以及本标准中涉及到“合同”的段落的解释。当各方（需方、供

45、方，或者生产方）允许根据本标准由供方管理文档编征服务时，本标准可能 被包含在合同或者类似协议中。项目或者组织也可将本标准作为内部标准，根据本标准管理文 档编征服务。3生存周期过程中的用户文档管理软件生存周期中的用户文档管理IS0/IEC 12207： 2022定义，用户文档管理是软件或者系统生存周期中的支持过程。用户文档随着 软件架构设计过程逐渐形成初级版本，在软件详细设计、软件构建，软件集成，软件测试和软件维护 活动中根据要求进行更新。注1 ：也可以是为先前发布的软件或者商业现货软件开辟用户文档；注2： IS0/IEC 26515软件与系统工程在敏捷环境下开辟用户文档中有更多关于用户文档开辟

46、和软件开辟之间关 系的信息。无论用户文档开辟是不是软件生存周期的一部份，文档都有自己的生存周期，包括一系列的过程实 现阶段；设计和开辟，生产和维护阶段。用户文档管理应应用于文档生存周期的其他活动中：a）分析和设计，包括为项目文档设计做准备的；采集软件产品和用户的信息、任务和需求；基于 这些需求设计文档；b）开辟和评审，包括根据合用性原则安排文档内容，通过编写文字和图形内容实施文档设计，在 指定的媒体上实施信息，编辑和评审文档的内容，评估用户文档和产品的其他部份；c）生产，包括文档的整合，编制，复制，包装和发布；d）维护，包括在软件产品的整个生存周期内，保持文档的准确性、控制文档版本，修改文档以提 高其易用性。按照ISO/IEC 12207-2022的要求，用户文档管理者应执行符合ISO/IEC 12207： 2022中636和7.2.1 的信息管理和软件文档管理的过程。注3：为了便于引用，附录B列出了这些过程的详细内容。