（工商管理专业论文）基于过程的软件质量管理改进实践——非软件公司质量管理改进研究.pdf

学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下， 独立进行研究工作所取得的成果。除文中已经注明引用的内容外， 本论文不包含任何其他个人或集体己经发表或撰写过的作品成果。 对本文的研究作出重要贡献的个人和集体，均已在文中以明确方式 标明。本人完全意识到本声明的法律结果由本人承担。 学位论文作者签名：巧夏耨 、1 日期：弘一7 年f 月，多日 学位论文使用授权声明 本人完全了解中山大学有关保留、使用学位论文的规定，即： 学校有权保留学位论文并向国家主管部门或其指定机构送交论文的 电子版和纸质版，有权将学位论文用于非赢利目的的少量复制并允 许论文进入学校图书馆、院系资料室被查阅，有权将学位论文的内 容编入有关数据库进行检索，可以采用复印、缩印或其他方法保存 学位论文。 学位论文作者签名：1 亥静 一 、 l 导师虢乡里手 心 日期：加郦年歹月舌日 | 基于过程改进的软件质量管理改进实践 一一非软件型企业质量管理改进研究 专业：工商管理硕士 硕士生：侯静 指导教师：彭建平副教授 摘要 随着信息技术的飞速发展，信息技术的使用给企业带来了翻天覆地的变化， 为了实现企业业务的流程整合和优化，增强企业的业务创新能力，提高企业的整 体生产效率和竞争力，信息技术平台的搭建已成为企业发展的趋势。而软件项目 又是企业信息化产业发展的核心，在企业信息化的过程中发挥着举足轻重的作 用。 随着软件的应用越来越广泛，企业业务规模的扩大化、全球化，人们对软件 的稳健性，可靠性的需求也日益增长，对软件质量的关注也达到了前所未有的高 度，软件项目产品的质量成为企业能够保证业务的稳健快速发展和获得更多用户 的关键。 目前越来越多的非软件型企业建立了自己的信息技术部门，这些部门除了承 担着企业的日常系统维护工作还要为企业开发新产品，同时企业的决策和战略发 展方向也依赖于信息技术部门提供的各种分析数据。在某些行业，信息技术部门 在企业中起着举足轻重的作用，如金融行业中的银行、证券公司，还有很多的中 小型企业。 但是如何更好得管理好这些非软件型企业信息技术部门相关的流程、技术、 人员? 如何使技术部门为业务提供更稳健的服务? 这些问题都成为企业c i o 们 非常关注的问题。 到目前为止，对于非软件型企业的软件质量的管理还是一个很少人关注的论 题。本文以c 公司为研究对象，比较了纯软件型企业和非软件型企业在软件信息 管理方面的异同，基于p d c a 持续改进的指导思想，以理论为指导，采取案例分 析法，经过深入的调查和研究，论述了c 公司对于该软件部门的软件质量管理改 进的过程实践，并总结经验教训，希望能为同类型的中小企业的软件质量管理提 供一些借鉴。 关键词：p d c a ，中小型非软件企业，信息技术部门，软件质量管理 i i t h ep r a c t i c a lm a n a g e m e n to fs o f t w a r eq u a l i t yb a s eo n p r o c e s si m p r o v e m e n t m a j o r ：m a s t e ro f b u s i n e s sa d m i n i s t r a t i o n n a m e ：h o uj i n g s u p e r v i s o r ：p e n gj i a n p i n g a b s t r a c t w i t ht h ei n f o r m a t i o nt e c h n o l o g yd e v e l o p m e n t ，i n f o r m a t i o nt e c h n o l o g yt a k e s d e e pc h a n g e st ob u s i n e s s b yt h ep l a t f o r mo ft h ei t , m o r ea n dm o r eb u s i n e s sc a n i m p r o v et l l e i rp r o d u c te f f i c i e n c ya n dc o m p e t e n c e s om a n yc o m p a n i e sb e g i nt ot a k e m o r ea n dm o r ei m p o r t a n ta c t i o ni nt h es o f t w a r eq u a l i t yo ft h ei n f o r m a t i o n t e c h n o l o g y w i t ht h ee x p a n d i n go ft h eb u s i n e s ss c a l e ，m a n yc o m p a n i e sp r o v i d eg i o b a | e n t e r p r i s es e r v i c e ，c r e d i b i l i t ya n ds t e a d i n e s so ft h es o f t w a r eq u a l i t yi sm o r ea n dm o r e i m p o r t a n tf o rt h ec o m p a n yt h eq u a l i t yo ft h es o f t w a r ep r o d u c ti st h ek e yf a c t i o nf o r t h eb u s i n e s st ok e e po nd e v e l o p i n ga n da t t r a c tm o r ea n dm o r ec l i e n t s n o wm a n yn o n s o f t w a r ec o m p a n ym a k eu pt h e i ro w ni td e p a r t m e n t s ，t h e s e d e p a r t m e n t sn o to n l yp r o v i d et h es y s t e mm a i n t e n a n c ea n dd e v e l o p m e n tn e ws o f t w a r e p r o d u c t i o n ，b u ta l s op r o v i d ed a t aa n a l y s i sf o rc o m p a n y i ns o m ei n d u s t r i e s ，t h ei t d e p a r t m e n t i s v e r yi m p o r t a n t ，s u c h a st h e b a n k ，t h es t o c k j o b b e ra n dm a n y m e d i u m - m i nt y p ec o r p o r a t i o n s b u th o wt om a n a g ei tp r o c e s s ，t e c h n o l o g ya n dr e l a t e dp e o p l eb e t t e r ? h o wt o p r o v i d em o r es t a b l es e r v i c et os u p p o r tb u s i n e s sb yi t ? t h e s ea r ew h a tm o s tc i o s o f t e nb e i n gp u z z l e da b o u t b yn o wf e wp e o p l eh a v ep u ta t t e n t i o no nt h es o f t w a r eq u a l i t yi m p r o v e m e n to fa n o ns o f t w a r em e d i u m m i nt y p ec o m p a n y t h i sa r t i c l et a k e st h ecc o m p a n ya s i i i r e s e a r c ho b j e c t ，c o m p a r et h ed i f f e r e n c eb e t w e e ns o t t w a r ec o m p a n ya nn o n s o f t w a r e c o m p a n y ，t a k e st h ep d c at h e o r ya sag u i d ea n dt h e nb a s eo nu p o nt h ec a s ea n a l y s i s ， t h r o u g ht h ed e e p l yr e s e a r c ha n da n a l y z e ，d i s c u s st h ep r a c t i c a lo fs o f t w a r eq u a l i t y m a n a g e ri nt h ecc o m p a n y t h e ns u m m a r i z et h ee x p e r i e n c ea n dl e s s o n s ，h o p et h e a r t i c l ec a ng i v es o m eu s ef o rr e f e r e n c et ot h es a m et y p eo ft h ec o m p a n y k e yw o r d s ：p d c a ，m e d i u m m i n it y p ec o r p o r a t i o n ，q u a l i t ym a n a g e m e n t i v 目录 j 摘要i a b s t r a c t i i i l i i录1 r 图目录v i i 表目录 第1 章引言 1 1研究意义1 1 2研究方法1 1 3研究内容及论文框架2 第2 章文献综述4 2 1软件的失败史4 2 2现代软件质量管理理论5 2 3评论与思考1 0 第3 章c 公司现状和问题分析。1 2 3 1公司背景1 2 3 2 公司发展战略规划1 2 3 3i t 中心的战略地位1 3 3 4 当前出现的问题1 4 3 5问题原因分析1 5 第4 章 c 公司软件质量过程改进实践 4 1持续改进模型2 0 4 2流程制定2 1 v 4 3k p i 制定2 8 4 4质量量化管理与分析3 0 第5 章质量改进效果分析4 6 5 1改进后的软件缺陷数据对比分析4 6 5 2用户满意度调查分析5 0 5 3基于持续改进的六s 波动分析5 4 第6 章总结。5 7 6 1经验和教训5 8 6 2不足和局限5 8 6 3建议5 9 参考文献。6 0 后 记6 2 v l 图目录 图i - i 论文结构图3 图2 - 3c m m 的5 个级别关系图9 图3 - ic 公司质量问题分析鱼骨图1 9 图4 - i 阶段数据流向简图2 2 图4 - 2v - m o d e l 测试模型2 6 图4 - 3 测试流程关系图2 8 图4 4 软件开发关键业绩指标2 9 图5 - 2c 公司改进前后缺陷d r e 对比4 8 图5 - 4 平均缺陷修复工时图4 9 图5 - 5c 公司k p i 指标分析对比5 0 图5 - 6 客户满意度调查结果5 4 图5 - 7 波动分析示例图5 5 图5 - 8k p i 缺陷率波动对比分析5 6 v i i 表目录 表4 - ic 公司持续改善管理流程2 0 表4 - 2 软件周期各阶段标准定义表2 3 表4 - 3 缺陷严重性等级表3 1 表4 - 4 缺陷优先级等级表3 2 表4 - 5 缺陷的生命周期分类表3 2 表4 - 6a 项目的缺陷统计及d r e 数据3 5 表4 - 7b 项目的缺陷统计及d r e 数据3 5 表4 - 8a 项目“缺陷注入一发现矩阵”表3 6 表4 - 9b 项目“缺陷注入一发现矩阵 表3 6 表5 - i 用户满意度调查表5 0 表5 - 22 0 0 7 年用户满意度调查统计表5 1 表5 - 32 0 0 8 年用户满意度调查统计表5 3 1 1研究意义 第1 章引言 随着信息技术的飞速发展，信息技术的使用给企业带来了翻天覆地的变化， 通过信息技术平台的搭建，实现企业业务的流程整合和优化，增强企业的业务创 新能力，提高企业的整体生产效率和竞争力，已成为企业发展的趋势。而软件项 目又是企业信息化产业发展的核心，在企业信息化的过程中发挥着举足轻重的作 用。 随着软件的应用越来越广泛，企业业务规模的扩大化、全球化，人们对软件 稳健性，可靠性的需求也日益增长，对软件质量的关注也达到了前所未有的高度， 软件项目产品的质量成为企业能够保证业务稳健快速发展和获得更多用户的关 键。目前很多企业都面临着信息技术部门内部的管理改进问题，但是如何进行有 效的管理和改进呢? 到目前为止，对于非软件企业的软件质量的管理还是一个很少人关注的论 题。是否需要向i t 公司一样进行专业的c m m i 认证呢? 需要投入多大的人力成本 进行质量改进呢? 用什么方法来指导企业的i t 部门进行持续改进呢? 本文以c 公司为案例，经过深入的调查和研究，论述了c 公司结合自身特点对p d c a ，c m m i 的理解，针对性的对该软件部门的软件质量改进实践，总结经验教训，希望能为 同类型的中小企业的质量管理提供一些借鉴。 1 2研究方法 本文主要采用文献研究法，定量分析法，案例研究法，经验总结法等方法来 研究软件项目的质量管理的方法和实际应用，研究方法的特点主要如下： 第一通过翻阅国内外相关软件项目质量管理的书籍和文献，深入研究质量 管理的理论和方法，并通过查询相关专业网站资料，获取相关信息和范例，并通 过理论学习和案例研究的基础上进行思考和总结。 第二研究质量管理的相关模型和方法，通过定量分析的方法，对质量管理 的认识近一步精确化，以便更科学的揭示规律，把握本质，理清关系，预测质量 管理的发展趋势 第三通过自身从事项目管理的多年经验，总结实用的项目质量管理理论和 方法，并通过具体的案例分析研究质量管理理论和方法在实践中的灵活运用，对 软件项目质量进行归纳和分析，使之系统化，理论化，通过实践经验来验证理论。 1 3研究内容及论文框架 本文主要由六个部分组成，各部分的具体内容如下： 第1 章：引言，主要介绍研究目的和意义、研究方法、研究内容及论文结构。 第2 章：基本理论综述：概要介绍了全面质量改进理论。然后详细介绍了 p d c a 的方法论和c m m i 基于过程的质量改进模型。 第3 章：c 公司现状和i t 问题分析：对c 公司公司的现状和目前所面临的 问题进行了详细的介绍和分析。 第4 章：c 公司软件质量改进实践：以中小企业为例，用提出问题分析问 题解决问题的框架，并结合p d c a 质量改进的方法论和模型，深入介绍了c 公 司的质量改进过程。 第5 章：质量改进效果分析：本章通过对缺陷率、客户满意度和六。波动 分析的对比，对质量改进的效果进行了分析。 第6 章：总结：得出本文的主要结论，列举了c 公司进行软件质量改进的 过程中所积累的一些经验和不足的地方，以供参考和借鉴。 2 引言 上 文献综述 上 l c 公司现状和r r 问题分析 土 i c 公司软件质量改进实践 土 l l软件质量改进效果评估 上 总结 图 - 1 论文结构图 3 第2 章文献综述 2 1软件的失败史 关于软件失败的文献相当多，最为大众所知的就是千年虫问题，人们对软件 错误所带来的后果严重性也是在这个事件上有了一个感性的认识。但是，大多数 人，甚至包括一部分软件程序的开发者都对软件产品出现的缺陷可能会造成什么 样后果没有预知性，往往只有在问题发生后才能进行补救，但是事后补救的代价 已经远远大于了事前的更正。更严重的是，在当今社会，软件的应用已经进入了 人们生活的方方面面，从发射火箭到银行的综合业务系统然后普及到人们同常生 活，大量的数据处理都是通过软件来实现，所以有些问题发生后，小则引起客户 的投诉和公司信誉的下降，大则能造成人身伤亡。 千年虫已经成为了历史，但是为了解决千年虫问题所花费的巨额资金无法让 人们忘记它，仅在英国，解决千年虫问题估计就花费了大约3 8 0 亿美元。而这一 问题的产生仅仅就是因为系统只用了两位数字来记录日期，仅此而已。但是一旦 这样的编码习惯成为了规范并代代相传下去，就带来了灾难性的后果，我们必须 将所有与日期有关的代码找出来进行必要的修改，然后一一验证所有与日期有关 的代码的正确性。 1 9 8 1 年，由计算机程序改变而导致的1 6 7 的时间偏差，使航天飞机上的5 台计算机不能同步运行，这个错误导致了航天飞机发射失败。1 9 8 6 年，1 台 t h e r a c 2 5 机器泄露致命剂量的辐射，致使两名医院病人死亡。造成惨剧的原因 是软件质量出了问题，导致这台机器忽略了数据校验。 1 9 9 6 年6 月4 日，阿丽亚娜5 型火箭发射器在起飞前3 7 秒的飞行一切正常， 但从第4 0 秒后开始，发射器偏离轨道，解体并发生爆炸。这次的失败使欧洲航 天局( e u r o p e a ns p a c ea g e n c y ，e s a ) 陷入困境，其可靠性也遭受了前所未有的 质疑。专门成立的委员会经过认真的调查发现，问题出在操作数错误引起软件计 算火箭航道出现了偏离，导致操作数错误的原因就是6 4 位浮点数向1 6 位有符号 4 整型数转换时出现了问题。 这些失败显示，在很多组织中软件质量都应该成为关键的成功因素，软件失 败的影响可能使纠正软件付出巨大的代价，或者造成重大的损失。随着软件越来 越广泛得被人们应用在各种地方，对软件质量的保证也越来越成为人们探索的重 要话题。 2 2现代软件质量管理理论 现代的软件质量管理理论是人们在质量管理大师的理论基础上，通过不断的 实践和研究，归结出现代化的质量管理方法，即全面质量管理( t o t a lq u a l i t y m a n a g e m e n t ，t q m ) 理论，它是- - f 3 管理哲学，它包括以客户为中心、过程改进、 开发组织内部的质量和度量标准以及分析程序等等。而它所遵循的科学理论就是 p i ) c a 持续改进方法论。各种持续改善的方法论的理论依据都是来源于p d c a ，包 括六西格玛管理理论( 6 s i g m a ) 、精益生产管理理论( l e a n ) 、全面质量管理理论 ( t q m ) 、i s 0 9 0 0 1 质量管理体系、能力成熟度模型集成( c 删i ) 等等。 2 1 2 持续改进方法论：( p d c a 循环) p d c a 循环又叫戴明环，是美国质量管理专家戴明博士首先提出的，它是全面 质量管理所应遵循的科学程序。全面质量管理活动的全部过程，就是质量计划的 制订和组织实现的过程，这个过程就是按照p d c a 循环，不停顿地周而复始地运 转的。 p d c a 是英语单词p l a n ( 计划) 、d o ( 执行) 、c h e c k ( 检查) 和a c t i o n ( 改进) 的第 一个字母，如图3 1 ，它是一种基于流程导向的方法论，p d c a 循环就是按照这样 的顺序进行质量管理，并且循环不止地进行下去的科学程序。 囡 图2 - 1p d c a 持续改善模型 全面质量管理活动的运转，离不开管理循环的转动，这就是说，改进与解决 质量问题，赶超先进水平的各项工作，都要运用p d c a 循环的科学程序。不论提 高产品质量，还是减少不合格品，都要先提出目标，即质量提高到什么程度，不 合格品率降低多少? 就要有个计划；这个计划不仅包括目标，而且也包括实现这 个目标需要采取的措施和流程；计划和流程制定之后，就要按照计划进行检查， 看是否达实现了预期效果，有没有达到预期的目标；通过检查找出问题和原因； 最后就要进行处理，将经验和教训制订成标准、形成制度。 p d c a 循环作为全面质量管理体系运转的基本方法，其实旌需要搜集大量数据 资料，并综合运用各种管理技术和方法。 p d c a 循环的特点有三个： 第一各级质量管理都有一个p d c a 循环，形成一个大环套小环，一环扣一环， 互相制约，互为补充的有机整体，如图3 - 2 所示。在p d c a 循环中，一般说，上 一级的循环是下一级循环的依据，下一级的循环是上一级循环的落实和具体化。 第二每个p d c a 循环，都不是在原地周而复始运转，而是象爬楼梯那样，每 一循环都有新的目标和内容，这意味着质量管理，经过一次循环，解决了一批问 题，质量水平有了新的提高，如图3 2 所示。 6 第三在p d c a 循环中，a 是一个循环的关键。 2 6 图2 - 2p d c a 循环 2 1 2i s 0 9 0 0 1 质量管理标准概述 i s 0 9 0 0 0 族标准是国际化( i s o ) 在1 9 9 4 年提出的概念，它的主要用途是为 企业建立质量体系、并提供质量保证的模式。i s 0 9 0 0 1 是i s 0 9 0 0 0 族标准所包括 的一组质量体系核心标准之一，是一个可以适用于所有行业的质量管理标准，它 将产品的实现过程流程化，更加适合软件组织的开发、生成的维护。 i s 0 9 0 0 1 标准包括八个部分：范围、引用标准、术语和定义、质量管理体系、 管理职责、资源管理、产品实现、测量、分析和改进。i s 0 9 0 0 1 针对合同环境下 设计、开发、生产、服务等环节，给出了最基本质量要求，并根据个企业的质 量体系中是否覆盖了所有质量要素( 以文档化形式) ，以及这些要素是否有效地 按定义方式实施来判断该企业是否符合i s 0 9 0 0 1 要求。 不过i s 0 9 0 0 1 依然强调的是传统的制造业的质量控制，它强调需求是不可改 变的，但是这些假设对于软件行业并不适合。 7 2 1 3 基于模型的过程改进( c 删i ) 概述 在现代软件质量管理领域里，c m m i 是迄今为止业界公认的最好的软件质量管 理模型。 1 9 9 3 年，美国国防部设在卡内基一梅隆大学的软件研究所正式发表了能力成 熟度模型，它是评估软件生产部门组织、厂家的软件生产能力成熟度的模型，是 从软件生产组织过程的角度，来评估软件生产部门达到的水平级别。由美国国防 部提出和倡导的以c m m 为核心的软件工程管理技术，经过近2 0 年来的研究、实 践和推广应用，已经得到世界各国的认可，成为当前这一领域的主流技术。 c m m ( c a p a b i l i t ym a t u r i t ym o d e l 能力成熟度模型) 的本质是软件管理工程的 一个部分。是软件组织在定义，实现，度量，控制和改善其软件过程的进程中各 个发展阶段的描述。他通过5 个不断进化的层次来评定软件生产的历史与现状。 2 0 c m m i ( c a p a b i l i t ym a t u r i t ym o d e li n t e g r a t i o n ) 将把各种能力成熟度模 型整合到同一个大的架构中去，并建立包括软件工程、软件采购和系统工程在内 的诸多模型的集成，解决除软件开发以外的软件系统工程、软件采购等工作中的 迫切需求。 1 1 为了在软件过程改进中便于操作，c m m 模型给出了每一个成熟度等级的详细 结构。每一级包含了实现这一级目标的若干关键过程域( k e yp r o c e s sa r e a ，k p a ) ， 每个关键过程域包含若干关键实践，无论哪个关键过程域，它们的实践活动都统 一按5 个公共特性进行组织，如图2 1 所示。 w 堰复极( 2 ) 欧锈黻籍镑理 绶代质豫城 f 舟| | ：| 嚣理 嚷i l 的j 垒踩黢握 唾曩键铋 麓求管缫 图2 3c m m 的5 个级别关系图 c m m i 把软件过程的成熟度分为：1 初级、2 可重复级、3 定义级、4 管理级和 5 优化级。这五个等级标志着企业软件开发的成熟度：描述了软件组织在定义、 实现、度量、控制和改善其软件过程中各个发展阶段；指明了一个成熟的软件组 织成功的过程改进的优化顺序，从而使软件组织逐步走向成熟。它为软件企业的 过程能力提供了一个阶梯化的进化框架。 在c m m i 模型中，最基本的概念是“过程域”，与以前的一些过程改进模型一 样，c m m i 模型也只是选择对过程改进最重要的一些题目，将其编组到“域”中， 它指明了一个软件组织在开发方面需要做哪些主要的工作，以及这些工作之间的 关系，次序和怎样一步一步地做好这些工作而使软件组织走向成熟。 c m m i 的主要特点： ( 1 ) 它重视过程改进过程中的可度量性、可见性和可管理性，重视系统化 和制度化。 ( 2 ) 它为组织提供了系统化建立、实施和改进过程中应该做什么，达到什 么目标，但没有说明如何做，采用哪些具体技术、方法和策略。 ( 3 ) c m m i 也被称为重载的模型，因为它要求组织在过程改进建设中付出大 量的努力，同时也需要企业投入大量的人力、物力。 ( 4 ) c m m i 的变更控制比较严格，它要求在开始的时候就要将需求固定、过 程剪裁固定下来，这在一定程度对于某些企业来说比较难以实现。 9 2 3评论与思考 c m m i 的模型和标准大多是为大型组织和大型项目开发的，并不是适合所有的 组织，也不完全适合中小型的非软件企业。对于中小型的非软件企业来说，要从 自身的组织结构、业务环境、人力和丌发资源出发，借鉴成熟的软件工程模型和 思想，对其进行剪裁和改进以适应特定的需要，找寻适合的管理方法去实施软件 管理过程的管理。 非软件企业的信息技术部门和软件企业的比较和思考： ( 1 ) 非软件企业的信息技术部门作为公司的一部分，主要的服务对象是本 公司，但是这并不影响信息技术部门作为一个独立部门的运作，与独立的软件企 业一样，信息部门生产软件产品同样需要遵循软件开发周期的流程，从需求分析、 设计i ! i i i 试和交付，从整个软件工程管理的角度来看，没有任何区别，所以软件 企业质量管理的理论和实践同样可以运用到非软件企业信息技术部门。 ( 2 ) 非软件企业自始至终都是服务于一个“客户 的，就是本公司，在整 个服务的过程中，虽然会穿插着各个新的项目的实施，但是总体的服务目标不变， 服务“客户不变，因为产品的稳定性，需求大致相同，所以信息部门提供的服 务有一个重要的特征，就是服务的持续性和长期性。在这样的情况下，持续改进 的思想就显得尤为重要。 ( 3 ) 与软件公司不同，非软件公司的信息技术部门不直接创造利润，特别 是中小企业，人员和资金都有限，而且企业也希望能够比较快得看到改造的效果。 以最少的投入取得最快最有效的成果，是大部分中小型企业对于软件质量改进的 普遍要求。所以如何才能寻找出一种简单而有效的方法进行质量的管和改进是非 常重要的。 根据上面的分析，c m m i 显然不适合中小型的非软件企业，原因有以下几点： ( 1 ) c m m i 虽然是目前为止最好的软件质量管理模型，但它是一种重载的模 型，就算要对c m m i 进行剪裁，也要对企业的人力和资金以及管理有比较高的要 求，而非软件型企业的i t 技术部门一般都很难达到这么高的要求。 ( 2 ) c m m l 只提出了应该做什么，达到什么样的标准，并没有明确应该如何 去做，这对于中小企业来说，对c m m i 的导入是比较困难的。大多数企业都不可 l o 能在培训和认证上支付太多的资金，因为c m m i 的认证对于非软件型企业来说是 没有特别大的意义。 综上所述，到目前为止，p d c a 持续改进原理还是最适合非软件企业进行软 件质量改进的理论。企业秉承这个理论，根据自身的特点，制订最有效的改进方 式，根据项目改进的结果，不断调整改进的方案，制订更高的目标，循环反复， 使整个部门的质量水平得到提高。而且在非软件型企业，信息技术部门提供的不 间断的服务方式也为持续改进提供了持续改善的条件。 第3 章c 公司现状和问题分析 3 1公司背景 c 公司正式成立于2 0 0 0 年9 月，最初公司的主营模式是以信息技术为基础平 台，通过网络提供房屋买卖信息，后逐渐发展为实体店经营，提供房屋中介服务。 公司拥有三大业务板块：中介业务板块、房屋金融业务板块、家居业务板块。集 团全面整合成员企业的资源优势，不断锐意创新，推出多项极具特色的置业服务 产品，致力于构建专业房屋服务体系。历时八年，在企业领导及广大员工的共同 努力下，c 公司形成了一个以跨区域全国连锁为基础，实体店与网络店相结合， 含括租售贷一体服务的全新中介模式，发展成为一个拥有八个城市分公司、4 0 0 多家连锁店面、5 0 0 0 多名员工的地产中介企业。 3 2公司发展战略规划 2 0 0 6 年，公司管理层根据市场环境和相关政策，提出了公司未来5 年的发 展规划： 三个突破 在业务快速成长，利润稳步增加的同时，c 公司在未来五年内要实现三个突 破： 实现经营区域由单一城市向多区域扩张、发展的突破。实现集团经营的 横向快速增长； 实现经营业务由中介业务为主，向围绕居住产业多元化服务的突破，实 现集团业务的纵向快速增长； 实现公司经营由大到强的突破。将公司由规模企业发展成为具有核心竞 争力的强势企业。最终形成具有自我生长能力的，持续领先的竞争优势。 1 2 成长目标 全国布局初步完成，成为国内最大的房屋流通服务商之一，房屋销售量 ( 二手) 居全国前三名，广东第一名； 利用渠道优势，整合业务运作，在广州地区成为充分利用客户资源的房屋 流通综合服务商，具备明显高于行业平均水平的运营效率： 经营业绩持续快速增长，公司治理完善，业务运作规范，成为具有良好品 牌美誉度和社会责任心的股份制企业。 具体指标 公司房屋中介业务进入1 5 2 0 个城市，初步完成业务渠道的全国布局， 全国营业网点预计超过1 0 0 0 家； 公司营业额超过1 5 亿元，纯利润超过1 5 亿元。五年期间营业额平均每 年增长7 2 ； 利用渠道优势，业务纵向延伸，非中介业务占公司利润2 0 以上，其中广 州市非中介业务争取占当地业务利润的4 0 以上； 具备明显高于行业平均水平的运营效率，公司人均创造收入1 5 万元月， 而在行业成熟市场( 如：广州、深圳等地区) 人均创造收入将达到2 0 万元月。 企业使命 以不断创新的业务运作模式，打造最具效率的房屋流通网络，让中国人住的 更好 3 3i t 中心的战略地位 c 公司是一间中介公司，中介公司本身就是靠信息和服务来赚取利润的，这 一特性决定了i t 部门在公司的重要性。无论是信息还是服务都是需要i t 技术的 支持，通过数据库来维护大量的房源和客源信息，然后通过网络为各个分店共享 这些信息，通过开发各种类型的产品为客户提供各类服务。 许多企业出于成本的考虑会将自己的i t 运营和维护进行外包，但对于c 公 司来讲，外包并不合适，有以下几点原因： ( 1 ) 外包并不会为c 公司节约多少成本。因为c 公司作为一家企业，其对 i t 的要求并不高，i t 中心的维护和开发人员并不都是专业人员，人员成本低。 外包公司作为专业的软件公司其专业的人员成本相对会高很多。 ( 2 ) 对数据的保密程度的要求比较高。c 公司的数据信息对公司来说至关重 要，如果数据信息泄露，将会使c 公司的生存受到很大的威胁，而且c 公司是一 家中小型企业，对软件开发的需求量不大，所以一般情况下，这类公司不会轻易 将i t 中心外包。 ( 3 ) 内部人员对公司内部的业务流程更加了解，进行运营维护或者产品开 发会更加高效。同时对于公司来说，实用公司的内部人员会更加安全。 随着c 公司的发展和扩张，i t 部门在c 公司作用也越来越深入和广泛，根据 c 公司的战略规划，i t 部门的工作也逐渐从业务驱动阶段开始向战略驱动阶段转 移，i t 部门不仅要提供日常的运营维护、系统升级和产品开发，还需要进行数 据分析，为管理者制订战略规划提供可靠的数据依据。这些都对c 公司的i t 部 门的管理有了更高的要求，但是目前公司的i t 部门已经出现了一些问题，但是 i t 部门领导认为这些问题只是一些表象，问题的根结还需要进步分析，同时 要适应公司的战略发展，对i t 部门进行质量管理改进已经是势在必行了。 3 4当前出现的问题 随着公司业务的逐步发展，规模的逐步扩大，使用业务系统的人数从之前的 8 0 0 多人逐渐增加到5 0 0 0 多人，业务系统也不断的进行着系统升级或调整的工 作，虽然软件开发部门的人数也在不断增加，人数也从2 0 0 0 年的6 人逐渐增加 到现在的5 0 人左右，但随着日积月累的业务调整和系统开发修改，业务系统在使 用和维护过程中逐渐暴露出一系列的问题： ( 1 ) 管理者看到的问题 第一系统统计的公司业绩和实收报表不能象以前按时生成并提交，不时会 发生延误统计的情况，导致管理者无法准时的知道公司业务数据，对于业务的管 理和推动造成了一定程度的影响。 第二系统统计的业务数据的准确率降低，不时会发生业务数据统计错误的 情况，导致管理者无法收到业务数据的真实反馈，对于管理者准确有效的进行公 1 4 第一系统的运行速度逐渐变得缓慢，交易的响应时间增长，在业务高峰时 期甚至会出现超时现象，无法正常的使用业务系统。 第二系统的稳定性降低，经常会出现系统的某些功能无法使用的情况，经 过i t 人员的检查和修复后，又可以使用，但同样的问题可能会在几天后有会出 现。 第三提交到i t 部门的新业务功能需求，无法及时的得到交付，交付的质量 不尽人意，总是存在这样或那样的问题，一个新系统的上线使用往往要经历卜3 个月左右的磨合或改进，才能慢慢进入稳定阶段。 ( 2 ) 软件开发人员看到的问题 第一通过系统监控看到服务器的资源有时会满负荷运行，有时甚至会导致 服务器崩溃，需要重新启动服务器才能缓解压力，但软件开发人员找不到导致系 统满负荷运行的根源，只能碰到问题，重启服务器，处于很被动的状态。 第二开发人员针对i t 支持和维护的工作剧增，每天都疲于受理和处理各种 各样的问题，每天都有重复的或新的问题产生，用户对于系统的抱怨也越来越多， 觉得系统的问题多，交付质量差，渐渐产生不认可系统，不认可i t 人员的工作 的态度。 第三开发人员每天大部分时间花在解决问题上，旧系统的问题层出不穷， 重复的问题不停的出现，新系统的开发也无法按计划进行，开发人员每天都处于 救火的状态，无法预知明天会有什么新的问题，工作处于混乱无序的状态，开发 人员在工作中得不到乐趣，无法认同自己的工作价值，团队士气日渐底下。 3 5问题原因分析 为分析上述现象产生的根源，改善现有的软件质量现状，2 0 0 7 年7 月，i t 中心软件开发部门成立了专门的软件质量改进小组，经过一个月左右的时间，对 软件开发部门现存在的问题进行了收集和整理，从流程、人员、技能三个方面进 行了问题的分析和总结。 3 4 1 流程存在的问题 c 公司的i t 中心软件开发部门将日常的工作内容分为项目开发和日常需求 开发两种类型，其中项目开发工作定义为需要耗费2 0 个人日以上的工作，包括 新系统的歼发和旧系统的改造，而日常需求开发是指需要耗费2 0 人日以下的工 作，一般是指旧系统的升级或改造以及日常的应用维护工作，针对这两种类型的 工作，经过调查和分析，主要在以下一些流程存在问题。 ( 1 ) 项目管理流程存在的问题 事实上，从调查的结果来看，c 公司的软件开发部门没有一个系统的项目管 理流程来规范和管理整个项目的过程。 从项目的需求分析开始，一般是业务部门提出需求之后，软件开发部门便开 始在分析中进行开发，虽然在需求分析的过程中会与业务部门进行讨论，但不会 形成需求分析之后的文档，往往是在边讨论的过程中边进行开发，对于讨论的过 程没有形成记录或整理成文档让用户进行确认，这样往往项目完成之后，才发现 所做的功能与用户的需求存在差异或不能满足用户的需求，需要再次开发。针对 一些研发性的项目，需求的设计来自与软件开发部门和业务管理部门，没有充分 考虑最终用户的使用习惯和需求，闭门造车，交付出来的产品质量不尽如意，无 法满足用户的实际需求。 ( 2 ) 项目开发流程存在的问题 第一采用瀑布式开发模型进行软件的项目开发。这种模型是比较早期的开 发模型，该模型将整个软件开发过程分为需求分析、设计、测试、投产、维护等 几个阶段，每个阶段有着固定的顺序，将生存期活动从上一个阶段向下一个阶段 逐级过渡，如同流水下泻，最终得到所开发的软件产品。采用这种模型开发的缺 点是，无法预知开发人员已经充分理解了需求或者交付的软件系统是否符合需 求，往往到了最后的交付阶段，才发现交付产品存在大量的问题或者根本不符合 用户的需求，造成大量的修改工作甚至是返工重新设计丌发，给公司带来巨大的 人力成本和时间成本的浪费。 第二开发各阶段的标准定义不清晰。软件开发人员不清楚每个阶段的开始 和结束的标准是什么，交付产物是什么，也不知道如何判断和检查每一阶段是否 已完成。由于没有这些标准定义，往往会导致开发过程中的某个阶段实际上并没 1 6 有完成，就已经进入了下一个阶段，由于上一阶段存在的问题或者未提供充分的 准备条件，导致下一个阶段的事情也无法顺利开展，困难重重，从而导致连锁反 应，导致最终的交付质量根本无法保证。 第三在软件开发中，各角色的工作定义不清晰。软件开发人员不清楚自己 在软件项目中应该做哪些事情，职责是什么，与其他开发人员的沟通标准是什么， 往往开发人员都是埋头苦干，独自作战，对自己的交付没有进行严格的单元测试， 开发人员互相之间也没有进行同级的检查和评审，开发人员源头的质量就已经无 法保证。 ( 4 ) 项目测试流程存在的问题 第一没有定义规范的软件测试流程。开发人员对于程序的测试仅限于本机 的单元测试，没有集成测试和用户测试的过程，开发人员的交付产品无法得到更 系统的测试和验证，导致上线的产品存在较多的缺陷，往往上线之后需要重复修 改多次，才能最终解决问题。 第二没有掌握系统测试方法。开发人员对于单元测试应该如何测试，该测 试哪些内容不明确，没有测试案例来指导测试，往往是凭感觉测试，或者是从单 一的角度去测试，导致测试出来的质量不能得到保证。 第三不重视或不进行压力测试。开发人员在测试过程中只是针对功能进行 测试，对于非功能性的指标譬如压力测试、稳定性测试等不重视，对于用户并发 量较多的功能，往往会出现在测试环境测试功能没有问题，速度也较快，但放到 正式环境使用时，频频发生速度缓慢或死机的现象，严重影响用户的使用效果。 ( 4 ) 配置管理流程存在的问题 第一没有形成统一的文档配置管理。对于需求文档、设计文档等，没有使 用版本管理工具进行统一的配置管理，只是以拷贝的方式存放在项目组成员每个 人自己的机器里。没有统一的文档版本，没有人知道从哪里可以获得最新的版本， 每个人都只是对自己手上的文档进行维护修改，导致同一份项目文档可能存在多 份不同的版本拷贝。即使是使用项目负责人的机器统一来管理文档的版本，但时 间一长，经过多个人的修改，就无法找回历史版本。 第二文档更新不及时。一些项目的设计文档在系统上线之后就停止了更新， 系统上线之后对发现的问题进行修复或对新的变更需求进行实现后，不会再继续 1 7 更新设计文档，时间一长，修改的东西越来越多之后，无法找到最新的设计文档， 对于与部门其他开发人员进行知识分享或转移时，无法通过文档来进行传递，需 要通过阅读生产环境的源代码才有可能读懂业务设