1. ・ 8 4 ・ 计算机应用研究 2004 年 软件缺陷分类的研究 聂林波, 刘孟仁 ( 海 军工 程大 学, 湖北 武 汉 430033 ) 摘 要: 软 件缺 陷分 类是 研究 软件 缺陷 管 理 的 基 础 。说 明 了 软 件 缺 陷 的 危 害, 阐 述 了 对 软 件 缺 陷 分 类 的 必 要 性, 考察 了国 内外 关于 软件 缺陷 错误分 类的 各种 方法 , 分 析了 各种 分类 法的 优缺 点, 提出 了一 个有 利 于 提高 软 件 质量 和改 进软 件过程 的分 类方 法, 指出 了缺 陷管 理系 统的 基本 功能 要求 并总结 了对 软件 缺陷 进行 分类 的意 义。 关键 词: 软 件缺 陷; 缺陷 分类 ; 软件 故障 ; 软 件失 效 中图 法分 类号 : TP311. 53 文 献标 识码 : A 文 章编 号: 1001 - 3695( 2004) 06- 0084- 03 Research on Software Defects Classification NIE Lin- bo, LIU Meng- ren ( Naval University of Engineering, Wuhan Hubei 430033, China) Abstract: Software defects management is built on the base of classification of software defects. This paper explains the harm of software defects, expatiates the necessity of classifying software defects, reviews some classification of software defects home and abroad, analyses the merit and flaw of each classification, brings forward a means of classification which would benefit ele- vation of software and improvement of software process, finally indicates the basic functional requirements of management sys- tem of defects and the significance of classification of software defects. Key words: Software Defect; Defect Classification; Software Fault; Software Failure 结果。软件失效是指软件出现如下的状态: 功能部件执行其功 1 引言 能的能力的丧失; 系统或系统部件丧失了在规定的限度内执行 软件缺陷是软件产品的固有成分。软件缺陷是软件“生来 具有”的特征。不管是小程序还是大型软件系统, 无一例外地都 存在缺陷, 这些软件缺陷, 有的容易表现出 来, 有的隐藏 很深难 以发现; 有的对使用影响轻微, 有的会造成财产甚至生命的巨大 损失。1991 年海湾战争中, 美军使用爱国 者导弹拦截伊拉克飞 毛腿导弹中, 出现过几次拦截失败事件, 后经查明是软件计时系 统的累积误差所致, 该软件缺陷使一个很小的系统时钟 错误积 累起来造成十几个小时的延迟, 致使跟踪系统准确度丧失, 最终 导致了严重的后果 [ 3] 。软件从最初的设计到最后 的退出使用, 需要开发人员、用户和维护人员的大量智力劳 动。为了 保证软 件正常运行, 必须对软件中存在的缺陷进行有效的管理。 2 所要求功能的 能力; 程 序 操作 背离 了 程序 需 求 [ 8] 。 缺陷 是 这 些故障和失效的源头。要想获 得高质 量的软 件就要 从消除 软 件缺陷着手。进行缺陷的预防、检测和消除工作。 不同的软件开发阶段会 产生不 同的缺 陷。缺陷存 在于 软 件生命周期的各个阶段。在问题定义阶段, 系统分析员对问题 性质、问题规模和解决方案 的考虑 不周会 引入缺 陷, 这种缺 陷 在软件开发的前期不易察觉, 只有到了软件的接受测试阶段甚 至投入使用后才暴露出来。对这类缺陷的预防是尤为关键的。 在定义需求规范阶段, 规范 定义不 完善, 这是 导致软 件缺陷 的 最主要原因。在系统设计阶 段, 错 误的设 计方案, 致使 系统 无 法实现。在编码实现阶段, 错误地理解了算法, 导致代码错误。 在测试阶段测试人员对缺陷出现条件判断错误, 修改了一个错 误, 却引出了更多错误。在维护阶段, 修改了有缺陷的代码, 却 软件缺陷概述 又导致了先前正确的模块出现错误。 缺陷是软件产品期望属 性的偏 离。软件没 有满足 规范 要 不同的软件缺陷会产 生不同 的后果。在时 间、人力、物 力 求以及用 户 的 期 望, 造 成 用 户 使 用 的 不 便, 就 是 软 件 缺 陷。 允许的情况下, 应修复 软件中 存在的 所有缺 陷。但是, 这只 是 SW- CMM 对其定义是: “系统或系统成分中的 能造成它们 无法 软件开发的一种理想情况。绝 大多数 软件项 目都是 要求按 期 实现其被要求的功能的缺点。如果在执行过程中遇到缺陷, 它 完成的, 而且给予项目的资源有限( 包 括人力 资源和 软件生 产 可能导致系统的失效 [ 6] ”。 资料) , 只有对软件 缺陷 进行 区别 对 待, 区分 其 严重 等级 和 优 在软件领域还有几个与软件缺陷相关的术语: 软件故障和 先等级, 将有限的资源充分 利用, 解决 对软件 产品质 量最为 关 软件失效。软件故障是软件没 有表现 出人们 所期待 的正确 的 键的软件缺陷, 才能生 产出用 户满意 的软件。另 一方面, 软 件 缺陷的修复代价。在软件生命周期的各个阶段, 相同的软件缺 收稿日期: 2003- 06- 06; 修返日期: 2003- 06- 28 陷的修复成本大不相同。随着时间的推移, 修复软件缺陷的费

2. 第 6 期 聂林波等: 软件缺陷分类的研究 ・ 8 5 ・ 用是呈几何级增加的。因此要 尽可能 早的发 现缺陷 并修复 缺 缺陷类型和缺陷 限定 词。ODC 对八 个属 性 分别 进行 了 分类。 陷。 其中缺陷类型 被分 为七 大类: 赋 值、检 验( Checking) 、算 法、时 对软件缺陷进 行分 类, 分 析产 生 各类 缺陷 的 软件 过 程 原 序、接口、功能、关联( Relationship) 。 因, 总结在开发软件过程 中不同 软件缺 陷出现 的频度, 制定 对 分类过程分两步进行。第一 步, 缺陷打 开时, 导致 缺陷 暴 应的软件过程管理与技术两方面的改进措施, 是提高软件组织 露的环境和缺陷对用户可能的影响是易见的, 此时可以确定缺 的生产能力和软件质量的重要手段 [ 4, 5] 。 陷 的三 个属 性: 发现缺 陷的 活动、缺 陷引 发事 件和 缺陷 影响。 第二步, 缺陷修复关闭时, 可以确定缺陷的其余五个属性: 缺陷 3 传统的软件缺陷分类方法 软件缺陷的分类方法繁多。各种分类方法的目的不同, 观 载体、缺陷类型、缺陷限定词、缺陷年龄和缺陷来源。这八个 属 性对于缺陷的消除和预防起到关键作用。 该分类方法分类细致, 适用于缺陷的定位、排除、缺陷原因 察问题的角度和复杂程度 也不一 样。几个有 代表性 的软件 分 类方法如下: ( 1) Putnam 等人 [ 9] 提出的分类方法将软件缺陷分为六类: 分析和缺陷预防活动。缺陷特 征提供 的丰富 信息为 缺陷的 消 除、预防和软件过程的改进创造了条件。IBM 的研究机构制 定 需求缺 陷、设计 缺陷、文档缺陷、算法缺陷、界面 缺陷和性能 缺 出该分类方 法 已经 十多 年。IBM 一 直在 改 进 ODC。 近几 年, 陷。 业界开始研究 并使 用 ODC。ODC 的 缺点 在于 分类 复杂, 难 以 国家军用标准 GJB- 437 根 据军用 软件错 误的来 源将软 件 把握分类标准, 缺陷分析人员的主观意见会影响属性的确定。 错误分为三类: ①程序错误, 运行程序与相应的文档不一致, 而 ( 4) 电气和电子工程 师学会 制定的 软件异 常分类 标准 [ 11] 文档是正确的; ②文档错误, 运行程序与相应的文档不一致, 而 ( IEEE Standard Classification for Anomalies 1044- 1993 ) 对 软 件 程序是正确的; ③设计错误, 虽然运行程序与相应的文档一致, 异常进行了全面的分类。该标 准描述 了软件 生命周 期各个 阶 但是存在设计缺陷, 可能产生错误。 段发现的软件异常的处理过程。 分类过程由识别、调查、行动 计划和 实施处 理四个 步骤 组 这两种分类方法可以分析软件缺陷的来源和出处, 指明修 复缺陷的努力方 向, 为 软件 开发 过 程各 项活 动 的改 进提 供 线 成, 每一步骤包括三项活动: 记录、分类和确定影响。异常的 描 索。分类简单是该分类方法的显著特点。因为分类方法简单, 述数据称为支持数据项。分类 编码由 两个字 母和三 个数字 组 所以提供的缺陷相关信息对具体的缺陷修复工作的贡献有限。 成。如果 需 要 进 一 步 的 分 类, 可 以 添 加 小 数。 例 如 RR324, ( 2) Thayer 软件错误分类方法 [ 3] 是 按错误 性质分 类, 它 利 IV321. 1。RR 表示识别 步骤, IV 表 示 调查 步骤, AC 表示 行 动 用测试人员在软件测试过程填 写的问 题报告 和用户 使用软 件 计划步骤, IM 表示确 定影 响活 动, DP 表 示实 施处 理步 骤。 分 过程反馈的问题报告作 为错误 分类的 信息。它包 括 16 个类, 类过程的四个步骤都需要 支持数 据项。由于 每个项 目都有 各 在这 16 个类之下, 还有 164 个子 类。16 类有: ①计算 错误; ② 自的支持数据项, 该标准不 强制规 定支持 数据项, 但 提供了 各 逻辑错误; ③I/ O 错误; ④数据加工错 误; ⑤操作系统 和支持软 个步骤相关的建议支持数 据项。强制 分类建 立通用 的定义 术 件错误; ⑥配置错 误; ⑦ 接口错误; ⑧用户 需求改变, 这是指 用 语 和概念, 便 于项 目之 间、商业 环境 之间、人 员之 间的 交流 沟 户在使用软件后提出软件无法满足的新要求产生的错误; ⑨预 置数据库错 误; ⑩ 全局变量 错误; 瑏 瑡 重复的错 误; 瑏 瑢 文档错误; 通。可选分类提供对于特 殊情况 有用的 额外的 细节。在调 查 步骤, 对实际原因、来源和 类型进 行了强 制分类。其中 调查 步 瑣需求实现错误, 这是指 软件偏 离了需 求说明 产生的 错误; 瑏 瑏 瑤 骤将异常类型分为逻辑 问题、计算问 题、接口 / 时序 问题、数 据 不明性质错误; 瑏 瑥 人员操作错误; 瑏 瑦 问题, 这是指软件问题报告 处理问题、数 据 问 题、文 档 问 题、文 档 质 量 问 题 和 强 化 问 题 中提出的需要答复的问题。 ( Enhancement) , 共八个大类, 下面又分为数量不等的小 类。分 该分类方法特别适用于指 导开发 人员的 缺陷消 除和软 件 类细致深入, 准确说明了异常的类型。 该分类方法提供一个统一 的方法 对软件 和文档 中发现 的 改进工作。通过 对错 误 进行 分类 统 计, 可以 了 解错 误分 布 状 况, 对错误集中的位 置重点 加以改 进。 该方法 分类详 细, 适 用 异常进行详细的分类, 并提供异常的相关数据项帮助异常的识 面广, 当然分类也较为复杂。该分类方法没有考虑造成缺陷的 别和异常的跟踪活动。IEEE 软件异常分类标准 具有较高的 权 过程原因, 不适用于软件过程改进活动。 威性, 可针对 实际的软件 项目进行裁剪, 灵活 度高, 应用面广。 ( 3 ) 缺 陷 正 交 分 类 ODC ( Orthogonal Defects Classifica- tion) [ 10] 是 IBM 公司 提 出的 缺陷 分 类方 法。该 分类 方法 提 供 一个从缺陷中提取关键信息的测量范例, 用于评价软件开发过 程, 提出正确的过程改进方案。 该分类方法用多个属性来描述缺陷特征。在 IBM ODC 最 新版本里, 缺陷特征包括以下八个属性: 发现缺陷的活动、缺陷 影响、缺陷引发事件、缺陷 载体( Target) 、缺陷年 龄、缺 陷来源、 不足之处是没有 考虑 软 件工 程的 过 程缺 陷, 并 且分 类过 程 复 杂。但是该方法提供了丰 富的缺 陷信息。缺陷 原因分 析活 动 可以充分利用这些信息进行原因分析。 4 基于过程的缺陷分类法 高质量高可靠性大型实时 软件系 统的按 期按预 算开发 存 在很大的困难。承担这类软件 开发的 组织需 要较高 级别的 软

3. ・ 8 6 ・ 计算机应用研究 件能力成熟度。为了满足软件开发组织实施缺陷预防、改进软 2004 年 进的建议等内容。 件过程和提高软件能力成熟度的需要, 必要的工作就是软件缺 缺陷管理需要结合缺陷 生命周 期。缺陷生 命周期 是指 从 陷管理。软件缺陷管理又 需要缺 陷分类 作为基 础。因此需 要 发现缺陷直到完成缺陷处理的过程。这个过程有六个状态: 缺 制定一个针对软件缺陷管 理的缺 陷分类 方法。分类 的目的 是 陷打开( Open) ; 缺陷分 析( Analyze) ; 缺陷修 改( Correct) ; 缺 陷 分析软件缺陷产生的过程原因, 改进软件过程, 预防软件缺陷, 搁置( Defer) ; 缺陷验证( Verify) ; 缺 陷关闭 ( Close) 。图 1 是 缺 改进软件质量, 提高组织的软件能力成熟度。该分类方法应满 陷状态转换图。 Open 足以下要求: 准确地对发 现的缺 陷进行 分类; 分类之 间应无 重 叠, 分 类 体 系应 覆 盖 所有 的 缺 陷类 型; 分类 要 与 软件 生 命 周 期 [ 1, 2] 有机结合, 从软件过程的角度对软件缺陷进行分类。 传统的软件缺陷分类方法主要是为了消除软件缺陷, 提高 陷分类方法, 在软件生命周期各个阶段中按照缺陷产生的所在 过程来分类。 软件生产是以过程为主 线的, 各种活 动都围 绕过程 进行。 各种工具和方法的使用都 和过程 紧密联 系。过程由 一系列 的 活动组成。这些活动由开发者使用工具、方法和技术完成。过 程之间是相互联系的。过程结 果会影 响到相 关的以 该过程 结 果为基础的过程。将分类方法 建立在 过程基 础上可 以更好 地 理解缺陷形成的过程, 把握缺陷的本质, 从根本上预防缺陷。 4. 1 分类过程 分类过程分为三个步骤: ①缺陷确认。根据测试人员提交 的缺陷报告重现缺陷, 确认测试对象存在报告宣称的缺陷。② Close 缺 陷状态 转换图 析缺陷原因寻求解决方案, 需要 及时修 复的要 确定修 复办法, 需要搁置延期修复的要说 明理由。缺 陷验证 是对修 改的缺 陷 进行检查, 确 认 修 改 成 功。Open, Analyze, Correct, Verify 是 活 动状态; Defer 和 Close 是终结状态。缺陷最终要停留在终结 状 态。缺陷信息数据库要记录每 个缺陷 的生命 状态并 及时更 新 缺陷状态, 这是缺陷管理的基本要求。软件开发人员要确保缺 陷状态能够顺利转换到终结状态。 软件缺陷分类方案不同, 采用 的缺陷 数据集 可能不 同, 但 最小数据集应该相同。最小数据集包括发现缺陷的检测活动、 引发缺陷的事件、缺陷 来源、缺陷 症状和 缺陷类 型。缺 陷数 据 应包括这个最小数据集。一个 供选择 参考的 缺陷数 据表表 头 设计如下: 缺陷 编号 发 现 活动 发 现位 置 引 发事 件 症状 类 型 状态 据一般包括发现缺陷的检测活动、引发缺陷的事件、缺陷来源、 4. 3 缺陷管理系统的要求 为满足大型的分布的软件开发环境的需要, 缺陷管理系统 的严重性等。③缺陷分类。根 据缺陷 数据将 缺陷划 归某个 产 生该缺陷的软件过程。 Verify Defer 缺陷打开状态是指缺陷 被发现 并被确 定。缺陷分 析是 分 缺陷测量。重现缺陷, 观 察缺陷 现象, 记录 缺陷数 据。缺陷 数 缺陷症 状、缺陷 的影响、硬件环境、软件环 境、缺 陷类型和缺 陷 Analyze 图 1 软件质量或是为了评价软 件的性 能和可 靠性。这些 分类方 法 不完全适用软件缺陷管理 的需要。因 此需要 设计一 个新的 缺 Correct 必须基于计算机网络, 采用浏览器 / 服务器结构, 使缺陷管理成 缺陷数据是缺陷分析活 动必需 的信息。通 过分析 缺陷 产 员通过 Web 浏览器获取缺陷数据, 处理 缺陷管理任 务; 利用 自 生的原因, 就可能消除软 件中尚 未被发 现的缺 陷, 尽 可能地 改 动电子邮件通知功能简化、加速和 改善团 队通信, 加 快缺陷 处 善软件质量。改进有缺陷的过程, 能够预防同类软件缺陷重复 理的速度, 提高缺陷管理的效率; 建立与项目一致的规则集, 使 发生。当组织的过程得到改进时, 软件组织的软件产品质量就 系统自动处理简单重复性任 务, 减 轻人员 的负担, 将 精力集 中 得以提高。 到缺陷原因分析上; 分配给 不同角 色的用 户相应 的权限, 保 证 不同开发组织、不同项 目制定 的软件 过程不 完全相 同, 应 管理工作的安全; 支持 结构化 查询语 言 SQL, 具有 强大 的数 据 根据自身的软件过程制定 具体的 缺陷分 类方案。基 于过程 的 搜索功能; 丰富的报表功能, 便 于组织 高级管 理人员 了解缺 陷 缺陷分类法的主要目的是分 离、检测并 消除缺 陷, 并 为预防 缺 管理工作的成效, 制定合理的软件过程改进方案。 陷积累经验, 寻找缺陷产生的过程原因, 改进软件工程过程。 5 4. 2 结论 缺陷管理 确定了缺陷分类方法, 缺陷的分类和管理就有章可循。由 为了生产出高质量的软件产品, 传统方法是通过软件测试探 于在软件生产过程的各种验 证、检查、测试和 分类过 程中产 生 测软件中的错误, 包括单元测试、集成测试等各个级别测试。更有 了大量的缺陷数据, 为妥 善管理 缺陷数 据, 必 须建立 缺陷数 据 潜力的方法是缺陷预防。通过缺陷原因分析, 确定缺陷原因并改 库, 实现缺陷数据管 理自动 化。 此外, 为了对 缺陷进 行统计 和 正缺陷, 确定并改正缺陷的过程原因, 改进遗漏缺陷的缺陷检测活 分析, 需要开发相应的软件工具辅助缺陷分析人员的工作。缺 动, 进行复查确保类似缺陷不再出现。通过如此严格缺陷预防过 陷分析人员定期报告缺陷 分析结 果。分析报 告应包 括缺陷 产 程必定能实现预期的质量目标。缺陷分类作为缺陷预防的有力工 生的原 因、缺陷 的危害性、修复的 优先级、缺陷出现的 频率、各 具, 对它的研究将促进软件组织的软件过程改进和软件产品质量 类缺陷的比例、对应的预 防措施、过程 的缺陷 和对软 件过程 改 的提高, 提升软件企业的竞争力。 ( 下转第 98 页 )

4. ・ 9 8 ・ 计算机应用研究 ( 1) 选择合适的描述方法和语言 计算机科学 人工智能 描述 Ontology 的方法有很多种, 如形式化、半形式化、非形式 化等, 根据 Web 信息的特点, 可以选择半形式化或形式化的方法。 数据库 神经网络 知识工程 知识表示 知识处理 知识库系统 决策支持系统 专家系统 演绎数据库 图 2 2004 年 已建 立的 一个关 于学 科的本 体 那么上面的简单查询就涉及到概念之间复杂的逻辑、语义 目前描述 Ontology 的语言和框架有很多, 有很多是基于 一 阶谓词的, 如 Ontolingua, Cycl, Loom 等。对于 Web 上的应用 而 言, 最好使用通用的语言来实现, 避免之间 的转换。XML 语 言 和 RDF 框架被认为是 Web 上数据交换 的标准, 有很 多基于 它 们的描述语言被定义出来: OIL, SHOE, RDFS 等。 和语法关系: Ontology层（ RDF Schema） 文档交换 Ontology 产品元 Ontology 生成的目录 Ontology 产品 Ontology 或内容 Ontology 专家是指在某领域具备深厚专业知识的人, 如参加或完成 相关领域研究和应用项目、发表 过相关 著作或 论文、教授相 关 数据模型层（ RDF） 目录文档的数据模型 商务部分 厂商等） （ 价格、 课程等人员都可能成为该领域的专家。假 设在 Web 上目 前有 如下人员的资料: < person > < name > < / name > < xlink ref = http: / / exp. edu. cn/ computers / Mary. html / > < Books > < Book > < title > Design and Realization of Expert System < / title > < topic > Software Design < / topic > < topic > Expert System < / topic > < publisher > Beijing Publish < / publisher > < publish time > 2001 < / publish time > < / Book > ... < / Books > ... < / person > 一般认为, 是某领域的子领域的专家同样也是这个领域的 语法层（ XML） 目录文档实例及元素 图 3 产品描述部分 属性等 ) (种类 、 B2B 电 子商务 信息 组织分 层 ( 2) 选择合适的创建 Ontology 方法 目前 Ontology 的开发还没有统一的标准, 不同的应用和 工 程所遵循的 创建 过程 和 方法 不同。 例如 现在 出 现的 方法 有: Mike Uscholddede & King 的骨架 法; TOVE 评价法; KACTUS 工 程法等, 在具体的应用中, 应该 根据应 用的特 点选择 和借鉴 具 体的创建和开发方法。 5 总结 专家, 所以应该是符合条件的结果输出。 可以看出这种基于本体和 语义的 信息检 索更接 近于实 际 语义 Web 是今后 Web 建立 的方向, 而 Ontology 对 其实 现 起着重要的作用。Ontology 基础 上的 语义 Web 在 很多 应用 方 情况, 更能获取到我们所需要的信息。 ( 2) 电子商务 面有着广阔的前景, 本文只讨论了其中的几个方面。要真正实 现语义 Web 并完成 Ontology 在它 上 面的 应用, 还有 很多 问 题 在电子商务中, 不同的商家可能采用不同的内容标准和目 录描述标准对其产品进行描述, 这就为他们之间的信息交互带 需要研究, 包括它在 Web 上的合适的创 建方法和框 架, 以及 成 功的实例。 来了困难, 因此, 在 B2B 的电子商务中, 需要解 决: ① 联合不 同 的内容和产品描述标准; ② 能链 接到不 同的目 录表示 标准; ③ 能联合不同的描述商业文档交互的标准, 如订单等。 参考文献: 本体在 B2B 的通信中能起到信息集成的作用。如图 3 所示。 在 Ontology 层定义不同 产品 和文档 标准 提供 的各 种信 息 [ 1] org/ 2000 / Talks / l206- xml2k- tbl / slide10- 0. ht ml , 2001 - 07- 20. [ 2] [ 3] 帮助其完成 Web 数据管 理, 突破 以前仅 仅只 是符 号和 数据 管 理, 还能进行语义上的处理和管理。 [ 4] 实现 在具体的应用和实现过程中, 应该注意以下问题: [ 1] 张海 藩. 软件工 程导 论[ M] . 北 京: 清华大 学出 版社, 1998. [ 2] 王立 福, 张世 琨 , 朱 冰 . 软 件 工 程 ——— 技 术、方 法 与 环 境 [ M ] . 北 京: 北京 大学出 版社 , 1997. [ 3] 作者简介: 邓 芳( 1972- ) , 副 教授, 研 究方向 为知 识工 程 、决 策 支 持、数 据 挖 掘及 数 据 仓库 。 Pittsburgh, Pennsylvania: Carnegie Mellon University, 1993. [ 7] JB 437 - 88, 军用 软件 开发规 范[ S] . [ 8] B / T11457, 软件工 程术 语[ S] . [ 9] utnam Lawrence H, Myers Ware. Measures for Excellence : Reliable Software on Time, within Budget [ M] . Prentice Hall, 1992. [ 10] am Chillarege, et al . Orthogonal Defect Classification: A Concept for 黄锡 滋. 软件可 靠性 、安 全性 与 质量 保 证 [ M ] . 北京 : 电 子 工业 出 ames S Collofello, Bakul P Gosalia. An Application of Causal Analy- s is to the Software Modification Proces[ J] . Software- practice and Ex- peri ence, 1993, 23 ( 10 ) : 1095- 1105. [ 5] ohn W Horch. Practical Guide to Software Quality Management [ M] . Norwood: Artech House , 1996 . [ 6] ark C Paulk, et al. Capability Mat urity Model SM for Software [ R ] . 邓志鸿 , 唐 世 渭, 张 铭, 等 . Ontology 研 究 总 述 [ J ] . 北 京 大 学 学 报, 2002, 38( 5) : 730- 738. In- proces s Measurements [ J ] . IEEE Transactions on Software Engi- neeri ng, 1992, 18( 11) : 943- 956. 版社 , 2002. [ 4] 杨 秋 芬, 陈 跃 新 . Ontology 方 法 学 综 述 [ J ] , 计 算 机 应 用 研 究 , 2002, 19( 4) : 5- 7. ( 上 接第 86 页 ) 参考文献: orys Omelayenko. Preliminary Ontology Modeling for B2B Content Integration[ EB / OL] . http: / / www. cs . vu. nl / ～borys, 2001- 01. 的术语。 另外, Ontology 在 Web 上 完成其 信息 定义 后, 还能 有效 地 4 B Lee. Semantic Web Architecture [ EB / OL] . http: / / www. w3. [ 11] EEE St d 1044-1993. IEEE Standard Class ificati on for Anomalies [ S] . 作者简介: 聂 林波 ( 1978 - ) , 男, 湖北 孝感人 , 硕 士研 究 生, 主 要 研究 方 向 为 软件 工 程 与软 件可靠 性; 刘孟 仁 ( 1940- ) , 男 , 湖 南 汨 罗 人, 教 授, 主 要 研 究 方 向 为计 算机软 件工 程、计算机 可视 化技术 。