Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC IEEE 26513定义了作为软件文档生命周期组成部分的测试和评审用户文档的要求。虽然许多组织在测试其软件产品方面投入了大量资源,但随附的用户文档往往受到的严格评估要少得多。该标准确立了用户文档必须经受与软件本身相同的系统验证和确认过程,认识到文档缺陷可能导致用户错误、支持成本和客户不满,就像软件缺陷一样。
标准定义了三种不同类型的文档评审,每种服务于不同的目的,需要评审者具备不同的技能。技术评审验证文档是否准确地代表了产品的功能、特性和行为——评审者必须能够在实际产品上执行文档化程序并识别任何差异。编辑评审根据语言质量标准评估文档,包括语法、术语一致性、风格指南遵守情况以及表达的清晰度。可用性评审评估文档是否使预期用户能够在预期的使用环境中有效、高效和满意地实现其目标。
每种评审类型都有定义的进入和退出标准。例如,技术评审需要稳定的产品版本或原型、已记录的评审范围以及具有适当技术专长的评审团队。退出标准包括按严重程度分类的记录结果、所有关键和主要结果的解决,以及由评审负责人签署的评审报告。标准强调应在整个文档开发周期中进行评审,而不仅仅在最后——对大纲和草稿的早期评审比对已完成文档的后期评审更具成本效益。
| 评审类型 | 关注领域 | 评审者所需技能 | 典型时机 |
|---|---|---|---|
| 技术评审 | 准确性、完整性、正确性 | 主题专业知识、产品知识 | 草稿完成后 |
| 编辑评审 | 语言、风格、一致性 | 技术编辑、风格指南掌握 | 开发全过程 |
| 可用性评审 | 有效性、效率、满意度 | 可用性工程、任务分析 | 编辑评审之后 |
标准引入了一个结构化的文档问题缺陷分类方案。缺陷按严重程度(严重、主要、次要、外观)、按类型(准确性、完整性、清晰度、一致性、可访问性、格式)和按位置(特定章节、图形、表格、程序步骤、代码示例)进行分类。这种分类可以系统跟踪文档质量指标,并识别文档开发过程中的系统性问题。
缺陷度量包括密度指标(每页或每个主题的缺陷数)和老化指标(按严重程度分类的缺陷解决时间)。标准建议基于组织历史数据或行业基准建立基准阈值。例如,每页超过0.5个严重缺陷可能表明技术评审阶段需要流程改进,而编辑缺陷增加的趋势可能表明风格指南偏离或作者培训不足。这些定量度量将文档质量从主观印象转变为客观管理的参数。
26513的一个独特贡献是其对文档可用性测试的详细要求。标准区分了可用性评审(基于既定可用性标准的专家评估)和可用性测试(与代表性用户进行实证测试)。可用性测试包括:定义代表用户目标的测试任务,招募与目标用户画像匹配的参与者,观察参与者仅使用文档尝试执行任务的情况,测量绩效指标(任务完成率、任务时间、参考文档的次数),以及收集主观满意度评分。
标准规定应在代表实际使用环境的环境中进行可用性测试,每个用户组至少需要五名参与者(基于已有的可用性工程研究,表明五名参与者可以识别大约85%的可用性问题)。可用性测试的结果直接输入到文档改进优先级中——导致任务失败或显著延迟的问题应以最高优先级处理,无论它们是否会在传统评审中被分类为严重问题。