（计算机应用技术专业论文）核心通信软件维护过程研究及工具实现.pdf

独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究成 果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含 其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他教育机 构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：差纽厘起日期：21 塑： 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即：研 究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保留并 向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借阅；学 校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段 保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文 核心通信软件维护过程研究及工具实现 核心通信软件维护过程研究及工具实现 摘要 随着通信软件的飞速发展，通信软件产品的日益增多，通信软件的维护越发重要， 维护过程中存在的问题也越来越明显，对于核心通信软件一即在通信网上提供增值 应用、增值业务及为运营商提供运营支撑的软件更是如此，这就迫切需要改进软件维 护过程，提出适用于核心通信软件的维护过程模型，指导维护活动，保证核心通信软 件的维护质量。 本文针对核心通信软件的特点，在分析几种维护过程模型的基础上，借鉴 c m m c m m i ( c 印a b i l 时m a n 斑t ym o d 州c 印a b i l 姆m a t 嘣t ym o d e lh n e g r a t i o n ) 中过 程改进的思想，提出适用于核心通信软件的维护过程模型，实现了基于该过程模型的 辅助工具并应用到实际维护过程中。论文提出的核心通信软件维护过程模型将维护过 程活动分为两大类，分别是基本过程类和支持过程类。与已有的维护过程模型相比， 基本过程类的过程活动对核心通信软件维护更具针对性，支持过程类则引入了 c m m ，c m m i 的思想。基于此核心通信软件维护过程模型，实现了过程辅助工具m s p ( m a n a g e l i l e n ts u p p o np l a t f o 姗) 并在b u t t 硼y 流程管理系统上定制了满足模型要求 的软件维护流程。m s p 系统很好的支持了核心通信软件维护过程模型中的支持过程 类，对于基本过程类的过程活动支持却不够规范，b 傩e m v 流程管理系统上定制的 软件维护流程则恰恰相反，这二者优势互补，配合使用能够发挥较大作用。 论文首先介绍了软件维护的概念和核心通信软件的定义及其维护的特点，然后分 析了已有的维护过程模型，在此基础上提出了适用于核心通信软件的维护过程模型并 对模型的两类过程活动进行了详细的设计，之后实现了满足核心通信软件维护过程模 型规则的辅助工具并应用于实践，最后作者对工作进行了总结和展望。 【关键词】核心通信软件，软件维护，软件维护过程 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文 核心通信软件维护过程研究及工具实现 l j k s e a r c ho fi v 【a i n t e n a n c ep r o c e s so fc o r et b l e c o m m u n i c a 廿o n s o f 呐a r e sa n di m p i e m e n t a t i o no fm a i n t e n a n c et o o i s a b s 劬c t w i t l lm ed e r e l o p i n m to ft c l c c o f m 删i i i c a t i o ns o f t w a r e s ，t h e i rm a i n t 咖c 髑b e c o m e m o 锄dm o i m p o 咖tm dt h cp r o b l 跗l si nm a i n t 朗衄c ep r o c 铭sa r cm o 咒o b “o w ， e s p e c i a l l yt om ec o r et e l e c o m n m i l i c a t i o ns o f t w a r 部1 1 l ec o r et d e 咖m u l l i 训o ns o r w a l e i s 也e et i l a tp r o 、r i d e sv a l u e - a d d e ds 硎c ea n do p e f a t i o ns u p p o r tf b ft e l e c o mc 枷e ls o 竹w a f em a i n t e i l a r l c cp r o c e s sm o d e ls h o u l db ei l e v e l o p e df o rc o r et e l e c o m m l l i l i c a l i s o 脚a 麟t oi n l p r o v c 吐璩麟i i i l t 懿岫c e 舯溉鹳 t h i st l l e s i sd i s c u s s e dt 量艟s o f t w a 他m a i n t e n 锄n m o e s sm o d e io fc o r e t e l e o d i n n l u n i c a t i o ns o f t w a r e s 柚d 嘶l a n e n t a t i o no fm a j n t a n c et 0 0 l s a c t i 、，i t i e so f m a i n t 饥a n c ep r o c e s sa d i v i d e di m ot 、v ot y p c si l lm es o f t 枷l f cm a i n t 衄a i l c ep r o c c s sm o d e l o fc o r et d e c o m m 岫i c a t i o ns o 竹w a r 锚o f 垃t y d eo fa c t i t i e si sc a l l e dp r i m a r yp r o c e s s 帮 觚dm eo t l l 盯i sc a 重l e ds u p p o m n gp r o c e s s 船c o m p a r es o 脚a r em a i n t 锄托c ep m c c s sm o d e l o fc o r et e l e c o i r l m u l l i c a l i o ns o r w a r ew i t 量io l h e rs o f t 、v 戤m a i m e n 锄c ep _ c i 器sm o d e l ， a c t i 、，i t i 鼯o fp r i m a r yp r o c e s s 嚣a r em u c hm o r cf i tf o rc o r et e l e c o m m u n i c a t i o ns o f t w 蝴 锄da c t i v i t i e so fs u p p o n i n gp r o c e s s e si n 仃o d u c ct h i l l l ( i n go fc m m c m m i b 鼬e d0 nm i s m a i m e n 锄c ep r o c e s s l o d e l ，t 、】l r ok i l l d so fm a i n t e n a l l c et o o l sa r ed e v d o p e d t h eo n ei s m 觚a g 叮n ts u p p o np l a t f b 吼觚dt l l eo m c ri sb u t t e r f l yw o r k n o wm a n a g 暇n e n ts ”l t 黜 t h c yc o o p 啪t e t 0a s s i s tp r o c 嘲o f 唧et e l e c o m 如n i c a 主i o n3 0 f 蛔a r em 丑j n t 锄孤l f o l | rp a 凼c o n s t i t u l 【ct l l et l l e s i s t h e6 r s t 口a r ti 1 1 舡o d u c e dt h eo o n c e p to fs o r w 撇 m a i l l t e n a n c e 趴dd 柚r a c l 鞠噶o fm a j n t 觚锄c ep 瑚i c i e s so fo o r et c l e c c 咀l m u l l i 删o ns o f t w 躺 t h es e c o n dp a r ta l l a l y z e dn l r e el 【i n d so f s o r w a f em a i n 晒m p 1 o c e s sm o d d b 龇o nn 】匝s t h e酬 p a r t 协螈) d u c c dt h e脚a r em a i n t 锄a n c ep r o c c s sm o d e l o fc o r e t e l e c o n m l 砌训s o f t w a r e sa n di m p l 锄锄o no fm a i n t 锄a n c et o l o l s ht h el 鹪tp a r to f t h i s 协e s i s ，t l l ew t c 矿s l l r 珈m a r i z o dt l l ew o r k 舭dp 瑚蹦t o dm en tw o r ko f m a i n t e n 锄1 o f r et d e c o n u n u n i c a 缸o ns o f h 棚：镩 【k e y r o r d 曩】c o 坞t e l 锄恤m 【l i c a t i o ns o 伽哪r e s o f h m a i 螂m a e s o 腑玳 m a j n t c 丑a p r o 嘲s 2 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 1 1 项目背景 1 前言 软件产品在交付使用后，它的生命周期并没有结束，接下来就要进入占到生命周 期6 0 左右的软件维护阶段。在过去的几十年中，软件维护费用逐步上升。7 0 年代 用于维护软件的费用只占软件总预算的3 5 4 0 ，8 0 年代上升为4 0 6 0 ，到了 9 0 年代则上升为7 0 8 0 。从占用时间和花费的费用上看，软件维护在软件产品 的生命周期中占有重要地位。但是，在很长一段时间里，人们对软件产品交付以后的 维护并未给予足够的重视。对于如何提高软件维护的质量和效率、如何使维护活动规 范化、如何改进维护活动等方面的研究与软件开发相比差距较大。 上个世纪6 0 年代，“软件危机”的出现，人们开始应用其它学科的成功技术( 如 建筑工程技术) 来发展软件系统，从而促进了软件工程这门学科的发展。随着软件工 程学科的发展，人们对于软件工程的研究逐渐从软件产品方面向软件开发过程方面转 移，于是引出了很多关于开发过程的研究和实践，提出了一些过程模型，并且开始了 软件开发过程的标准化工作。开始时，人们只是重点关注开发过程方面的研究，随着 人们对软件维护重要性的认识，到了9 0 年代，开始多方面着手全面系统地对软件维 护开展研究。但是，在我国，软件维护却一直没有引起足够的重视。随着我国软件行 业的发展，软件维护问题的出现，软件维护正在我国引起关注。 二十世纪末本世纪初，随着通信软件的飞速发展，通信软件产品的同益增多，软 件产品交付后的维护活动也随之增多，维护过程中存在的问题也越来越明显，这就迫 切需要改进软件维护过程，提出适用于通信软件的维护过程模型，指导维护活动，保 证通信软件的维护质量，提高客户对通信产品运行期间的满意程度。 作者在北京邮电大学网络与交换技术国家重点实验室进行研究生学习过程中，从 事通信软件开发与维护过程改进和质量管理工作。在导师廖建新教授指导下，从中获 得很多宝贵的知识和经验。论文内容正是对作者参加科研项目工作的总结。 1 2 论文内容 本论文是在对作者研究生期间实践工作总结和思考的基础上形成的。 论文分为三大部分： 第一部分内容是一些基本知识，包括软件维护概述、核心通信软件维护特点及软 件维护过程模型和模型分析。 第二部分内容是本文的中心，介绍了核心通信软件维护过程模型及维护过程辅助 北京邮电大学网络与交换技术国家重点实验室 5 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 工具实现和应用。包括第四章和第五章。 第三部分内容包括对整体工作进行总结及致谢、参考文献。 由于时间有限，和本人学识有限，文中不当之处，敬请批评指正。 6北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 2 1 软件维护概述 2 软件维护 2 1 1 软件维护的概念 软件维护的任务 1 ) 改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷。 2 ) 因为在软件使用过程中数据环境发生变化或处理环境发生变化，需要修改软 件以适应这种变化。 3 ) 用户和处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总 体性能要求，就需要修改软件以满足这些要求。 软件维护的类型 1 ) 改正性维护( c o r r e 幽v em a i m e l l a l l c c ) 改正性维护是为了识别和纠正软件错误，改正软件性能上的缺陷，应当进行 的诊断和改正错误的过程。 2 ) 适应性维护( a 咖t i v em 豳t 锄c e ) 适应性维护是为了适应外部环境或数据环境等可能发生的变化，而去修改软 件的过程。 3 ) 完善性维护( p e 睡c t i v em a i n t a i l c e ) 完善性维护是为了满足用户提出的新的功能或性能要求，需要修改或再开发 软件，以扩充软件功能，增强软件性能，改进效率，提高软件的可维护性。 4 ) 预防性维护( p 懒硼t i v em a i n t 锄c c ) 预防性维护是为了提高软件的可靠性、可维护性等。 在整个软件维护阶段所花费的全部工作量中，预防性维护只占到很小的比 例，而完善性维护几乎占到一半的工作量。软件维护活动所花费的工作量占整个 生存周期工作量的7 0 以上。这是由于在漫长的软件运行过程中需要不断对软件 进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要 花费很多的精力和时间，而且有时修改不正确，还会引入新的错误。同时，软件 维护技术不像开发技术那样成熟和规范化，自然消耗的工作量就比较多。 软件维护的定义 正如前面所述，软件维护的类型是多样的，不同类型的维护有不同的定义。 在国标g b 厂r1 1 4 5 7 8 9 中明确指出软件运行、维护阶段是软件生存期中的一部分， “对软件产品进行检测，以期获得满意性能；当需要时对软件产品进行修改以改 北京邮电大学网络与交换技术国家重点实验室 7 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 正问题或对变化了的需求做出响应”。可见，这是从软件生命周期层面对软件维 护做出的定义。从另一方面看，软件维护是一种技术措施，需要从技术的角度加 以说明。 国标g b ，r1 4 0 7 9 9 3 脚中对软件维护的定义是： 一 软件维护是指软件产品交付使用后，为纠正错误、改进性能或其他属性 或使产品适应改变了的环境而进行的修改活动。 这个定义与e e l 2 1 9 p 1 对软件维护的定义是相同的。 i s 伽e c1 2 2 0 7 州中对软件维护的定义是： 软件维护是指由于软件产品出现问题或需要改进丽对代码及相关文档的 修改，其目的是对软件产品修改以保持其完整性。 在本论文中软件维护使用国标g b 厂r1 4 0 7 9 9 3 对软件维护的定义。 2 1 2 软件维护在软件生命周期中的位置 软件在开发完成，交付使用后，它的生命周期并没有结束。任何一个软件都要经 历：系统定义，软件计划，需求分析，系统设计，编码，测试，验收运行，维护升级， 最后废止的时间过程，这一过程称为软件的生命周期。有资料统计，在整个软件生存 周期的时间分配来看，交付运行后的维护过程占有重要比例软件维护占软件生存 周期的6 7 左右。 软件维护过程开始于软件产品交付之后，结束于软件产品退役之时。但是关于软 件维护问题的考虑应该在软件生命周期的开发阶段就予以考虑。实际上在整个软件生 命周期中软件维护与软件开发是并行的且两者联系紧密。在开发的不同阶段要考虑到 以下维护问题。 在需求分析阶段：明确维护范围及责任；审查系统要求；研究运行维护的支持； 明确性能要求及变更；明确功能的扩充或收缩；检验关键资源的可扩充性。 在设计阶段：考虑系统的扩展、压缩、变更及设计通用性等。 在编程阶段：查找源程序错误，度量源程序可理解性等。 在测试阶段：维护人员参与集成测试，统计分析错误等。 软件维护问题在软件生命周期中考虑的越晚，维护的花费就会越大，难度也会越 大，从而造成昂贵的软件维护费用。因此，应该在软件开发阶段尽早的考虑软件维护 问题。本论文主要针对软件维护过程研究，重点关注软件交付后到软件退役之间的软 件维护活动，软件开发阶段中有关软件维护的活动不是本论文关注研究的重点。 8北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文 核心通信软件维护过程研究及工具实现 2 1 2 核心通信软件维护的特点 通信软件种类繁多，包括核心算法软件、运行在交换机上的信令协议栈软件、运 营支撑软件、增值应用软件和终端设备软件等。 作者研究的是核心通信软件的维护过程。本文对核心通信软件的定义如下： 核心通信软件指在通信网上提供增值应用、增值业务及为运营商提供运营支撑的 软件，例如智能网、彩铃、网管系统等，不包括终端设备侧的软件，例如智能手机上 的软件。 2 2 1 核心通信软件关注维护过程的必要性 首先，通信软件必须满足运营业务的需要，为了在激烈的通信市场竞争中取得优 势，各运营商不断地推出新业务，这就要求已运行的通信软件产品不断更新以满 足新业务的需求，对已运行通信软件产品的更新属于维护的范畴： 其次由于通信产品的飞速发展，相应地要求应用软件的版本也必须快速更新，应 用软件版本的更新也属于维护的范畴； 另外，因为当前国内通信软件的开发还不够规范，通信软件常常未能在测试阶段 充分做好检测工作，提交用户的软件质量不高，在运行中容易出现问题，解决运 行软件的故障问题也属于维护范畴； 最后，为了提供服务的连续性，支持系统升级，也需要对电信软件进行维护。 2 2 2 目前通信软件维护存在的问题 目前通信软件维护的质量参差不齐。存在问题主要有以下几个方面： 有些企业，没有规范的通信软件维护过程，维护的过程是不可预见的，混乱 的。 维护的质量完全是基于个人能力，维护人员对系统的熟悉程度、对维护活动 的了解程度决定了维护的质量和效率，因此往往是熟练的维护人员才能提供 好的维护，新手往往在提供维护的过程中问题频生，不能保证维护的质量。 维护过程文档不全，不能将维护资料以一个知识库的形式保留下来，如果人 员流失，那么积累起来的维护经验也随着维护人员的离开而消失。 2 2 3 核心通信软件维护的特性 不同类的软件因特点不同，维护活动也必然存在差异，核心通信软件在维护活动 中也有其自身的特性。 在现网运行的软件因为对实时性和可靠性的要求，对维护的质量要求较高，规定 电信级产品的年停机时间不超过3 分钟，因此对于核心通信软件的维护过程更要重视 北京邮电大学网络与交换技术国家重点实验室 9 北京邮电大学硕士学位论文 核心通信软件维护过程研究及工具实现 质量。同时因为面向的客户是各地的运营商，设立负责维护的组织结构也有自身特点， 一般公司都会设立维护机构，同时不同的地区会设有相应的维护现场工程师，负责接 收客户的维护需求，软件开发公司内部会有维护人员负责处理维护需求。 鉴于核心通信软件维护过程存在的问题及特性，迫切需要有效的方法或者模型来 指导此类维护过程，下一章将介绍已有的维护模型，并对这些模型进行分析。 1 0 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 3 软件维护过程模型 软件维护过程指在软件维护期间所采取的影响更改的一系列行动。模型这个词， 是指一系列更改的抽象表示，通过这些更改，软件产品从最初的构思进入到可投入使 用的系统。对于软件维护来说，模型就是专门针对软件进化的过程部分的表示。 白上个世纪7 0 年代开始，人们提出了不少维护过程模型。在软件维护过程模型 的发展过程中，传统具有代表性的软件维护模型有如下三种： 快速修改模型 b o d 蚰模型 i e e e 维护模型 3 1 快速修改模型 快速修改模型”堤一种软件维护的临时定制方法，是一种“救火”方法，等待问 题出现，然后尽可能迅速的解决( 模型如图l 所示) 。在快速修改模型中，不对软件 的波及效应或对代码结构的影响等这些长期效应进行分析就实施修改。 快速修改模型在适当的环境中会非常有效，例如，如果系统是由一个人开发和维 护的，那么他对系统有足够的理解，有能力对是否更改、如何实现更改做出本能的判 断。这种情况下，采用快速修改模型，可以使维护工作快速、经济的完成。但是这不 是一种典型环境，我们必须考虑在更常见的有很多客户的商业运作环境中这种模型的 使用。在这样的环境中，使用快速修改模型在很大程度上是因为有截止同期和资源压 力。如果软件公司仅仅依靠快速修改，就会遇到成本很高的难题，因此会丧失在最初 阶段使用快速修改模型所得到的任何优势。但是可以把快速修改模型集成到另一个更 精细的模型中，快速修改作为一种在外界压力下应急的更改方式，修改完成后，再根 据精细的模型要求采取一定的措施。 图1 快速修改模型 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文 核心通信软件维护过程研究及工具实现 3 2b o e h m 模型 1 9 8 3 年，b o c h m 根据经济学模型和原理，提出了维护过程模型( 模型如图2 所示) 柳。模型将维护过程分为四个阶段，分别是管理层决策、实现更改、软件 交付和评估。b o e h m 模型把维护过程表示为闭合环路，此模型由管理层决策阶段 来推动维护过程。在这个阶段中，通过运用具体策略并对所提出的一组更改进行 费效评估，确定一组经过批准的更改，随通过批准更改一起，还有实施更改的专 用预算。 这个模型侧重于管理层决策，侧重于规定批准更改的策略，使维护活动在投 资和效益之间取得一个平衡。这个模型是从经济利益的角度来驱动软件维护过 程。这个模型对于维护组织的管理层适用，基于这个过程，可以使组织制定合理 的维护策略，作出满足组织效益的维护决策。 3 3 m e e 维护模型 1 2 图2 b h m 模型 随着软件业的发展人们认识到需要对软件维护进行标准化，据此，m e e 计 算机学会软件工程标准化分委会颁布了“i e e e 软件维护标准”( m e e1 2 1 91 9 9 3 ) 嘲。该标准详细阐述了管理与执行软件维护活动的迭代过程，该过程模型包括软 件维护的输入、处理、控制及输出。该标准指出，应该在规划软件开发的时候进 行软件维护规划。模型如图3 所示。 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 修改请 图3 i e e e 维护模型 下面详细说明e e 维护模型的各阶段旧： 1 ) 问题更改鉴别、分类与优先级别的确定：软件维护起始于一个对软件的更 改请求，通常该请求由用户、程序员或管理人员提出。该请求以更改请求单 ( 础r ) 的形式提交，该更改请求单既可能是改正性维护也可能是适应性、完 善性、预防性维护，由维护机构确定其是何种类型，划分到合适的维护类别 中( 改正性维护、适应性维护、完善性维护或预防性维护) ，并确定其处理的 优先级别。每一个申请都必须分配一个唯一的编号，其数据输入一个数据库 ( 知识库) ，以便跟踪该请求。收集、审查度量和指标要求从这个阶段开始。 2 ) 分析：在此阶段，先进行维护的可行性分析，在此基础上进行详细分析。可 行性分析主要确定软件更改的影响、可行的解决方法及所需的费用等内容。 详细分析则主要是提出完整的更改需求说明、鉴别需要更改的要素( 模块) 、 提出测试方案或策略、制订实施计划。最后由配置控制委员会( c c b ) 审查并 决定是否着手开始工作。 3 ) 设计：在设计阶段，汇总全部信息以便审查并用于软件更改的设计，这些信 息包括系统倾目的文档、分析阶段产生的结果、源代码、知识库信息等。本 阶段应更新设计基线、更新测试计划、修订详细分析结果、核实维护需求。 4 ) 实现：在实现阶段，制订程序更改计划以便进行软件更改。实现阶段主要包 括如下过程：编码与单元测试、集成、风险分析、测试审查准备，更新所有 的文档。 北京邮电大学网络与交换技术国家重点实验室1 3 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 5 ) 系统测试：系统测试主要测试程序之间的接口，以确保系统满足原来的需求 以及新增加的更改需求。回归测试是系统测试的组成部分，主要是确保不要 引入新的错误。测试数据库对于回归测试是必不可少的。 6 ) 验收测试：验收测试是在完全集成的系统上进行的，并由用户或第三方来完 成，在验收测试期间，测试人员应该完成如下工作：报告测试结果、进行功 能配置审核( 确定系统功能是否满足功能需求) 、建立软件新版本( 或基线) 。 此外，还应准备软件文档的最终版本，包括系统文档和用户文档。系统文档 包括高层的系统流程、系统功能描述、源程序清单以及描述数据流的文档， 这些文档应完全置于软件配置管理的控制之下，用户文档由用户手册、错误 清单、培训资料及使用系统的功能说明等组成。文档应该与系统并行地更新。 一旦文档和验收测试完成，系统就该进入交付阶段了。 7 ) 交付：此阶段是将新的系统交给用户安装并运行。供应商应进行物理配置审 核( 确定所有的配置项目是否都交付了) 、通报所有用户、进行文档版本备份、 完成安装与训练。交付后，系统使用就开始了。 较之前的几种模型，i e e e 模型详细规定了软件维护过程的各种活动，作为标准， 可以适用于所有的软件维护过程。但是，对于不同的软件，因其特性不同，维护过程 必然也有所区别，i e e e 模型是一个大而全的规范，针对不同的软件，应该对过程进 行剪裁，同时细化一些过程的任务。 3 4 维护模型分析 快速修改模型只适用于“救火”的情况，此模型不能保证核心通信软件维 护过程高可靠性的要求； b o c h m 模型适用于维护组织的管理层，是从经济利益的角度来驱动软件维 护过程，侧重于规定批准更改的策略，对于更改实现过程规定不多，此模 型同样不能保证核心通信软件维护过程高可靠性的要求，而且对于核心通 信软件的维护而言，重点应该关注的是维护质量和可靠性，而不是批准更 改的策略； m e e 模型是一个大而全的规范，适用于所有的软件维护过程，并不仅仅针 对核心通信软件维护过程，因此，模型规范的活动范围太广，没有根据通 信软件维护的特点进行详细规定，而且m e e 模型对于保证维护过程质量方 面规定的活动不多，没有单独对软件维护过程起到支持作用的过程类进行 说明。 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 通过上述分析我们发现，已有的模型对核心通信软件维护过程而言，都有着或多 或少的不足，因此需要提出一种针对核心通信软件维护过程的模型，依据核心通信软 件维护过程的特点，借鉴已有维护模型的思想，来指导核心通信软件维护过程。 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 4 核心通信软件维护过程模型 4 1 核心通信软件维护过程模型 通过研究已有的软件维护过程模型及软件维护标准，结合过程改进模型 c m m c m m i ( c 印a b i l i t ym a t i l r i t ym o d e l c 印曲i l 酊m a n l r i t ) ，m o d c li n t e g r a t i o n ) 思想 及实践经验，针对核心通信软件维护的特点，提出了如图4 所示的应用于核心通信软 件维护过程的过程模型。 1 6 图4 核心通信软件维护过程模型 过程模型中的过程要素分为两大类： 基本过程类，这些基本过程类构成核心通信软件维护的主要工作流程； 支持过程类，这类过程贯穿整个维护流程，可以被基本过程使用，为基本过 程提供支持，这类过程对软件维护的质量有着举足轻重的意义。 从图4 中可以看到，通信软件维护过程从通信软件产品交付到现网上运行 开始，一直到软件退役结束。起始点和结束点之间的维护过程是一个基于现网 运行软件版本螺旋上升的过程。从初始版本开始，因为维护需求的提出，处理 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 后使软件产品的版本发生更改，接下来再提出系统更改需求，是基于变化后的 软件版本，这样每次更改都会带来软件版本的变化，随着一次次的执行维护流 程，软件的版本不断上升，直到最终退役。 4 2 基本过程类 一v 基本过程类的各个过程要素组合在一起，按照模型图中的顺序执行下来，即 构成了核心通信软件维护过程的基本工作流。 4 2 1 维护过程开始实施点 在维护过程的起始点，即维护过程开始实施之处，需要对维护过程进行规划， 为软件维护作准备。维护准备活动包括： 1 ) 确定维护机构，指定维护人员； 维护机构的设立，人员的组织形式及维护人员的多少根据机构的现状而定。 2 ) 应用通信软件维护过程模型定义维护机构的维护过程规范； 根据核心通信软件维护过程模型的具体规定，按照维护机构的设立方式，将各 个过程的任务分配到具体的机构部门，根据组织的规模进行模型任务的合并或者剪 裁，生成适用于本组织的维护流程规范。 3 ) 维护过程角色指派 核心通信软件维护过程模型涉及到如下几种角色：管理者、维护人员、提出人 员、分析人员、解决人员、评审人员、测试人员、升级人员。不同的角色职责不同， 维护机构根据实际情况，为具体人员赋予过程角色。各角色主要职责如下： 管理者职责： - 确认提出人员提交的问题报告单； 一 根据问题性质指定相应的分析人员、解决人员和维护人员； - 审核并决定是否批准解决人员提交的软件修改申请； 一 协调相关人员的工作，包括维护人员、提出人员、分析人员、解决 人员和评审人员； - 对产品维护流程的实施进行监督。 维护人员职责 全程动态跟踪一次产品维护流程实例的整个过程； 一 维护相关文档； 提出人员职责 一 确定系统更改需求的初始编号； 北京邮电大学网络与交换技术国家重点实验室 1 7 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 - 填写问题报告单； 一 提供与问题相关的信息； 接收来自分析人员和解决人员的反馈。若有必要，提供进一步详细 的信息。 分析人员职责 一 对问题进行分析并提出分析结果； 一 提出解决方案和测试方案； - 填写问题分析报告。 解决人员职责 根据问题分析报告中提出的解决方案解决问题； - 向管理者提交软件修改申请； 填写问题解决报告，软件修改报告、软件升级报告； 测试人员职责 对改进后的软件产品进行测试： - 生成测试报告等相关文档。 评审人员职责 对问题分析报告提出的分析结果的准确性进行评审； 对问题分析报告中提出的解决方案和测试方案的可行性进行评审； - 对问题解决的结果和测试结果进行验证； 升级人员职责 向客户提出升级申请 - 负责对系统具体的升级操作 4 ) 对维护人员进行培训 倘若维护人员非原有系统的开发人员，则要对维护人员进行产品培训、使维护 人员熟悉系统。除了产品培训，还应对维护人员进行维护过程的培训。如果条件允 许，建议对维护人员进行“与客户打交道”方面的培训，尽力提高客户对产品和开 发方的满意度。 4 2 2 提出系统更改需求 软件维护起始于一个对系统的更改请求，通常该请求由用户、现场维护工程 师或开发人员提出。该更改需求最终以问题报告单的形式提出。对于用户提出更 改需求的情况，一般是用户直接向产品的技术支持人员或现场维护工程师提出， 用户不可能生成问题报告单，因此就需要技术支持人员或现场维护工程师与用户 1 8北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 沟通，了解用户的实际需求，由技术支持人员或现场维护工程师生成问题报告单。 问题报告单的参考格式如表l 所示。问题不仅仅包括故障，同时也包括需求和功 能的增加。对于每一个申请都必须分配一个唯一的编号。 表1 问题报告单 潮缫润阌圈黼 年月 日 i 鬻该人j 翰壁鬻缓嚣i 蚓年 月日 初始编号： 问题内容： 近期操作： ”耱爹渗戮$ 帮”“一“。季嚣辫茹j 、；潦i f j i 辫一。拣蒸零擎冀。；澎鬻飘i ? 蓼匆i 鬟羹蕊豢震 。 n。，j一 ”“ r ”， 笺 。 。 交藤氟菇 女赫搬鬻溉藏躐豢滋嘲赫瀚麓瀛蕊熬融# 蕊荔蒌鏊瀚麓辘# 攀黛巍勰瓤嘏瓣蕊蕊鬻蠡瀛 目前处理方法： 嬲耀警擘警零瞬谬零嗲鬻誉穆躜罗霉罗碧琴鬻 瑟。嘲篓熬麓蕊。：瑟藏麓蠹i ；i l 囊灞鑫。l 囊汝# 瀛蘸誊! i i 囊。袋女l 瓠螽瓣纛赫；薹巍赢黧：飘i i 惑& 如瀚 严重程度： 提出人员： i 髑溺；鬣瀚i 瞧i & 器黪巍鬟麓爨黧l 豪，鬟鼹黧 = = 鬟黪鬻缀i 鏊麟浚囊；慧i ? 鬟爱骚蘩鬃 分析人员： 此阶段主要包括的过程活动有： 1 ) 用户或者现场维护工程师根据产品在现网出现的问题填写问题报告单 并提交到组织内部负责维护的部门；或者，开发人员根据软件产品内部 改进需要填写问题报告单； 2 ) 向管理者提交问题报告单： 3 ) 管理者确认问题报告单，并确定过程活动中的角色和任务分工； 4 ) 指定的维护人员开始跟踪此维护过程，可以生成一个系统跟踪文档，通 过在不同阶段更新状态来跟踪此次维护。 北京邮电大学网络与交换技术国家重点实验室1 9 北京邮电大学硕士学位论文 核心通信软件维护过程研究及工具实现 4 2 3 需求分析 此过程的主要负责人为分析人员，分析人员对系统更改需求即问题报告单进 行分析，包括问题定位，问题涉及的具体产品及相应的修改规模，给出具体的解 决方案，问题涉及到的文档，提出测试方案及策略等，最终形成问题分析报告。 分析人员对系统要有一个全局的认识，也就是说要理解主要功能模块之间交互的 整体情况。 问题分析报告的参考格式如表2 所示： 表2 问题分析报告 此阶段主要包括的过程活动有： 1 ) 分析人员根据问题报告单和相关产品手册讨论分析问题所在，在分析定 位结束后提交相应的问题分析报告。分析的内容主要包括： 类型：判断解决此问题的途径是纠正、改进、预防还是对新环境的 适应： 范围：确定问题涉及的具体产品及相应的修改规模： 解决：判断此问题是否与以前的某个问题完全相同。即根据问题现 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 象判断问题是否是已经发现的问题。如果此问题尚未发现过，需要 生成一个新的问题编号。然后确定解决人员、预计解决时间、并提 出解决方案。若暂时不能提出彻底的解决方案，则应提出目前的应 对方案。如果此问题已出现过，应在问题分析报告中的进行标注， 给出曾经问题的问题编号和相关的文档。 文档：判断源程序的修改涉及到哪些文档的修改； 测试：如果需要测试，确定测试的内容和目的、测试方案以及预计 测试时间。 2 ) 此流程结束后，维护人员在系统跟踪表中更新状态。 4 2 4 分析评审 此过程是保证维护质量的一个手段，可以使存在的问题尽早发现，降低维护后期 发现问题的风险。 分析人员根据问题的难易程度，问题修改涉及面的大小，以及对此解决问题的把 握能力来决定采取何种评审方式进行评审。 评审方式分为两种：一种是正式评审，一种是非正式评审。 正式评审需要走严格的评审过程，对于问题影响较大，问题较难，分析人员对问 题把握不够的情况需要按照正式评审的方式进行评审。 非正式评审指不走严格的评审流程，分析人员直接发送检查包，等待评审人员审 阅回复即可。对于问题影响不大，问题比较容易解决的情况可以采用这种评审方式。 正式评审的流程如图5 所示： 北京邮电大学网络与交换技术国家重点实验室 2 l 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 i 通知评审 + i准备 l l谖审会 i i 根据评审意见修改 l跟踪 l 图5 正式评审流程图 通知评审：管理者和分析人员一起选择评审人员，由管理者指定评审负责人； 分析人员将待评审的工作产品，作为检查包打包，发送给评审负责人；评审 负责人确定评审会时间、地点、设备，根据问题的情况评审负责人选择评审 准备的天数，从而确定评审会时间；评审负责人发布评审通知； 准备：评审人员认真审阅待评审工作产品。审阅过程发现的问题和疑问记录 下来，形成文档。评审人员需提前将评审问题记录发给评审负责人。 评审会：评审负责人主持会议，把握会议进程；评审人员提出疑问和问题； 分析人员对疑问和闯题做出解释；记录员作详细的问题记录；将待评审工作 产品评审完毕，评审负责人代领评审人员对评价决议达成一致，做出评审结 论通过( 无需复审) ：无需修改或需纠正一些小问题。不通过( 需复审) ： 需做重大修改，需重做，或评审会因某些原因未完成；评审组长或记录员会 后完成评审记录和评审问题列表，交由所有评审员签字确认。 根据评审意见修改：评审负责人在评审会结束后将评审问题列表分发给分析 人员，并和分析人员确认解决期限；分析人员对照评审问题列表对工作产品 进行修改，并在解决期限内完成修改。 跟踪：评审负责人在修改期限对照评审问题列表检查每个问题是否修改完 成，对于分析人员认为不需要修改的问题，判断分析人员的决策是否合理， 北京邮电大学网络与交换技术国家重点实验室 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 并修改问题状态( 关闭未关闭) ：对于需复审的工作产品，继续开评审会复 审。 此阶段主要包括的过程活动有： 1 ) 分析人员确定采用何种评审方式进行评审； 2 ) 评审人员对问题分析报告中提出的分析结果的准确性以及解决方案和 测试方案的可行性进行评审，具体评审过程依据不同的评审方式确定。 3 ) 若评审通过，维护人员在系统跟踪表中更新状态；若没有通过评审，则 应将此问题重新进行分析定位。 4 2 5 系统修改实现 解决人员根据问题报告单、问题分析报告和相关产品手册对产品进行修改。 解决人员在修改软件时，首先要理解程序，理解程序的最终目的是能够成功的实 现所要求的更改。在理解程序时，必须做到以下几点： 理解程序的功能和目标。 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构土、 控制结构、数据结构和输入输出结构等。 了解数据流信息，即所涉及数据来源何处，在那里被使用。 了解控制流信息，即执行每条路径的结果。 理解程序的操作要求。 一般来说，理解程序包括三种活动：阅读有关程序的文档、阅读源代码、运行程 序，人们对理解过程建模如图6 所示嗍： 图6 理解过程模型图 阅读有关程序文档。在这个阶段，解决人员要浏览、仔细阅读不同来源的信 息，例如系统文档，包括规格说明和设计文档，以建立对系统的总体理解。 北京邮电大学网络与交换技术国家重点实验室2 3 北京邮电大学硕士学位论文核心通信软件维护过程研究及工具实现 可以使用附有结构图、数据流图和控制流图的文档。如果系统文档不正确、 过时或者不存在，可以省略这个阶段。 阅读源代码。在这个阶段，可以实现对程序的全局和局部了解。全局了解可 以从顶层理解系统，确定更改可能对系统其他部分带来的副作用的范围。局 部了解使程序员能够集中精力到特定的系统部件上。通过局部了解，可获得 有关系统的结构、数据类型和算法模式。诸如用于检查源代码的静态分析器 等工具可在这个阶段使用。这些工具可以产生交叉引用表，指示不同的标识 符都在程序的什么地方使用。 运行程序。这个步骤的目的是研究实际程序的动态行为，例如执行程序并获 得跟踪数据。运行程序的好处是可以发现仅仅通过阅读源代码很难发现的系 统的某些特性。 在实践中，理解程序的过程并不是以这种有序的方式展开的，往往要通过各种活 动的迭代和回溯澄清疑问和获得更多的信息。 理解程序后，根据理解来修改软件。修改程序时会带来副作用，解决人员要了解 可能带来的副作用，以便在程序修改时加以注意。修改程序的副作用包括以下几个方 面。 修改代码的副作用。在使用程序设计语言修改源代码时，有可能引入错误。例如 删除或修改一个予程序、删除或修改一个标号、改变程序代码的时序关系、改变占用 存储的大小、改变逻辑运算符、修改文件的打开和关闭、改造程序的执行效率，以及 把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变，都容易引入错 误。 修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配， 因而导致软件出错。 修改文档的副作用。对数据流、软件结构、模块逻辑或任何其他有关特性进行修 改时，必须对相关技术文档进行相应的修改。否则会导致文档与程序功能不匹配、缺 省条件改变、新错误信息不正确等错误，使得软件文档不能反映软件的当前状态。 此阶段主要包括的过程活动有： 1 ) 解决人员理解程序； 2 ) 解决人员提交软件修改申请，申请软件出库。具体过程根据配置管理过程中 变更控制流程执行； 3 ) 若软件修改申请得到批准，则解决人员根据问题报告单、问题分析报告和相 关产品手册对产品进行修改，并按照