（国际贸易学专业论文）TDSCDMA基站项目管理研究.pdf

摘要 进度、质量和成本是项目管理中非常重要的三个要素，它们相 互作用，相互制约，成功的项目管理首先是要平衡这三者之间的关 系。 本文以t d s c d m a 基站项目为例，分析这一项目的进展情 况。基站是t d s c d m a 系统中重要组成部分，是直接与用户终端 接口的设备，它的稳定性、承载量直接关系到终端用户的通话质 量。t d s c d m a 基站项目于2 0 0 2 年6 月1 日启动，项目历时1 5 个 月，项目定位于开发最大支持9 载扇的基站设备。文中着重从进 度、质量和成本几方面全面分析了项目的执行情况，对其中出现的 问题进行分析，并总结了经验与教训。 关键词： 项目、项目管理、t d s c d m a 、基站 2 a b s t r a c t t i m e ，q u a l i t ya n dc o s ta r e t h et h r e em o s ti m p o r t a n tp a r t si np r o j e c t m a n a g e m e n t 1 1 1 e yr e s t r i c ta n da f f e c t e a c ho t h e r h o wt ol e v e lt h e r e l a t i o n s h i p so ft h e s et h r e ep a r t sh a sb e c o m et h ek e yr e q u i r e m e n to f p r o j o c tm a n a g e m e n t i nt h i sa r t i c l e ，w eu s et h et d - s c d m an o d e bp r o j e c ta sa n e x a m p l e n o d e bi so n eo ft h em o s ti m p o r t a n tp a r t so ft d s c d m a s y s t e m , w h i c hi st h ei n t e r f a c ew i t hm o b i l ep h o n e t h es t a b i l i t yo f n o d e bd i r e c t l ya f f e c t st h ec o m m u n i c a t i o nq u a l i t y t h et d s c d m a n o d e bp r o j e c ts t a r t e di nj u n e1 ，2 0 0 2 ，w h i c ht o o k1 5m o n t h s t h et a r g e t o f t h i sp r o j e c tw a st od e v e l o pat d s c d m an o d c bw i t h9c a r r i e rw a v e a n ds e c t o r s w em a i n l ya n a l y z et i m e ，q u a l i t ya n dc o s tt h e s et h r e ep a r t s i nt h i sa r t i c l e ，a n ds u m m a r i z et h ee x p e r i e n c e sa n dl e s s o n s k e yw o r d s ： p r o j e c t ，p r o j e c tm a n a g e m e n t ，t d s c d m a ，n o d e b 3 一、项目与项目管理 ( 一) 项目的含义 项目的实施通常是某一组织实现战略规划的手段。项目并没有一个十分明确的定 义，但是根据项目的特征，我们可以这样来认识项目：即为提供某项独特产品或服务所做 的i 临时性努力。临时性是指每个项目都有其确定的开始和确定的终止。独特性是指其产品 或服务在某些特殊的方面有别于所有其它的产品或服务。o 对于许多组织来说，项目是对 组织的日常运作范围内无法解决的问题的一种应对手段。项目是在组织中的所有层次上进 行的。项目可能仅需一人，也可能需要成千上万人的参与。完成项目可能需要几个星期， 也可能需要几年的时间。项目可能只涉及组织中的一个单位，也可能要跨越若干个单位。 项日是战略的实施手段，因此对执行项目的组织来说，项目对其经营战略能否实现至关重 要。 ( 二) 项目管理的含义 项目管理就是将各种知识、技能、工具和技术应用于项目之中，以达到项目的要 求。o 项目管理是通过诸如启动、规划、实施、控制与收尾等过程进行的。美国项目管理 学会将项目管理划分为九大领域，分别是：项目整体管理、范围管理、时间管理、成本管 理、质量管理、人力资源管理、沟通管理、风险管理和采购管理。现实中项目管理的各个 阶段与各个管理范畴是相互制约，相互影响，交替进行的。 项目管理中，项目的时间、成本和质量几个方面构成了三角制约关系，如何平衡好 三者之间的关系，也成为项目管理领域的一个关键问题。本文以一个t d s c d m a o 基站项 目为例，从项目管理的时间、成本、质量进行分析，剖析项目进行中的问题及经验教训， 并提出相关建议。 = 、t d s c d m a 基站项目背景概述 t d - - s c d m a 是一种全新的无线通信技术标准，它是由中国第一次提出并在此无线 传输技术的基础上与国际合作，完成了t d - - s c d m a 标准。这是中国移动通信界的一次 创举，也是中国对第三代移动通信发展的贡献。在与欧洲、美国各自提出的3 g 标准的竞 争中，中国提出的t d s c d m a 已正式成为全球3 g 标准之一，这标志着中国在移动通信 领域已经进入世界领先之列。这一系统既可以单独运营，也可以与其他无线接入技术配合 使用。t d s c d m a 系统特别适合应用于城市人口密集地区，可以提供高密度大容量话 音、数据和多媒体业务。 o 摘自p m b o k 2 0 0 0 o 摘自p m b o k 2 0 0 0 。t d s c d m a ：t i m ed i v i s i o n s y n c h r o n o u sc d m a ，即时分同步码分多址接入，是由中国提出 的一种全新无线通信的技术标准。 5 图l 所示为t d s c d m a 的一种组网结构。图中n o d eb 即为基站设备，基站是t d s c d m a 系统中重要组成部分，是直接与用户终端接口的设备，它的稳定性、承载量直接 关系到终端用户的通话质量。 蛔node b】nodeb k、nodebv 绉一 c o r en e t w o r k ( c n ) 刁d o m a l n 藻 i u - c s 二_ 汇訇 二 由 “i u - p s 一 厂可 二l j 、ll 墅! 堡! ! ! 、“l u b c ” il ui n t e r f a c e ( 图1 ) ( 二) t d - s c d m a 基站项目背景介绍 t d s c d m a 基站项目于2 0 0 2 年6 月1 日启动，项目定位于开发最大支持9 载扇的基 站设备。项目目标：从2 0 0 2 年6 月1 日至2 0 0 3 年8 月3 1 日，完成基站的研发和测试工 作。项目预算共计1 8 0 0 万元，预计投入人力9 0 0 人月。 本文以t d s c d m a 组合产品的计划为基准，对其中基站的项目管理情况进行总结分 析。系统集成、系统测试、现场测试的资产占用等数据由于涉及多个产品、多个项目，此 处按估算计入基站项目。 三、t d - s c d m a 基站项目状态 从2 0 0 2 年6 月1 日日项目启动到2 0 0 3 年8 月3 1 日，项目经过了研发、实体测试、 系统集成测试、系统测试和现场测试，以及生产前置、样机生产、q e 测试，共历时1 5 个 月。经过长时间的系统稳定性测试，于2 0 0 3 年9 月1 4 日向客服部发布i 临时准出版本，所 提交的功能、性能特性符合特性递交计划。 项目进行期间同时完成了产业化过程，生产环境初步建立。根据设备产业化过程中反 馈的生产j 题，基站进行了改版生产，这为以后的工作奠定了良好的基础。q e 测试方 面，基站已完成振动试验、电源拉偏试验、低温试验等一系列的q e 测试。 以下将从进度、质量、成本几方面来分析项目的管理情况。 6 ( 一) 进度分析 t d s c d m a 基站项目于2 0 0 2 年6 月1 日启动，2 0 0 3 年8 月3 1 日完成系统测试，项 目历时1 5 个月，项目进行情况如表l 所示： 一个新的设备在开发完成以后首先需要经过联调测试和白箱测试。以保证单个设备的 性能。之后设备进入整个系统迸一步调试，由此进入黑箱测试，系统集成、系统测试和现 场测试阶段。 由于工期紧张，项目计划自黑箱测试阶段使用快速跟迸的方法进行，这在一定程度上 增加了项目风险。 基准计划实际执行情况 项目启动2 0 0 2 - 6 - l2 0 0 2 6 - l 需求分析 2 0 0 2 6 - l 一2 0 0 2 - 6 2 8 2 0 0 2 6 1 _ 2 0 0 2 - 62 8 总体设计 2 0 0 2 7 1 2 0 0 2 - 7 - 1 02 0 0 2 7 1 2 0 0 2 7 - 1 0 概要设计 2 0 0 2 7 一1 1 _ 2 0 0 2 - 9 - 1 3 2 0 0 2 7 - l l 一2 0 0 2 - 9 - 1 3 详细实现2 0 0 2 9 - l 瑚0 0 2 1 2 1 3 2 0 0 2 8 1 2 2 0 0 2 - 1 2 1 3 单板实现2 0 0 2 9 1 瑚0 0 2 1 l - 2 9 2 0 0 2 8 1 2 2 0 0 2 - 1 1 - 2 9 软件实现 2 0 0 2 1 0 - 1 6 2 0 0 2 1 2 一1 32 0 0 2 9 - 1 0 0 2 1 2 一1 3 预集成 2 0 0 2 1 2 1 3 _ 2 0 0 3 1 1 72 0 0 2 - 12 - 13 _ 一2 0 0 3 一l - 1 7 联调测试 2 0 0 3 1 2 0 _ 一2 0 0 3 - 2 2 8 2 0 0 3 1 2 0 - 2 0 0 3 2 - 2 8 白箱测试 2 0 0 3 3 1 2 0 0 3 4 3 02 0 0 3 3 一i - 2 0 0 3 6 - 3 0 黑箱测试 2 0 0 3 4 l _ 2 0 0 3 - 5 - 3 0 2 0 0 3 禾l 一2 0 0 3 - 6 - 3 0 系统集成( s i ) 2 0 0 3 5 8 2 0 0 3 6 - 3 02 0 0 3 - 5 8 - 2 0 0 3 - 6 3 0 系统测试( s t ) 2 0 0 3 6 扛2 0 0 3 7 3 12 0 0 3 6 - 2 2 0 0 3 7 - 3 l 现场测试( f t ) 2 0 0 3 6 - l l 一2 0 0 3 - 8 - 3 l 2 0 0 3 矗l l _ 2 0 0 3 - 8 - 3 l 样机生产 2 0 0 3 - 2 1 0 2 0 0 3 5 - 3 02 0 0 3 - 2 1 瑚0 0 3 6 6 q e 测试 2 0 0 3 3 1 5 2 0 0 3 8 3 12 0 0 3 3 一1 5 2 0 0 3 - 8 3 l ( 表1 ) 根据表1 所示，绘制甘特图( 图2 ) 如下。甘特图所示为实际工作时问，红色三角标 示出计划时问与实际的差异。由甘特图可以清晰看出，研发阶段的各个里程碑都按时完 成。测试各阶段里程碑时间均有所延长。样机生产与基准计划相比也有所延迟。延迟原因 将在下面进行分析。 7 f 。丁 ：了 if f i 。f 下 ：可 i i了 |fi _ i 了 i i了 了 百 嚣t l了 t i ： 了 t i 了 i i ：丁 li l 了 i 百 ：可 ii i f t 鼍 i了 了 下 ； 2 g ! 2 =了 l lt t ：芎 i了 t 下 ：t lt t m 一t - 虿 鼍丁 it 了 i ；芎 l了 ， 了 i 丁 了 丁 l 亨 l 一t t ：t i 女 了 =i l li 苎暑 牟 li l； i l l ii 交建 羹圣 _ il l =! i苎 _ =!i l i女 篝 童 妻 iliii ill ii 璺曼 童 l l i 牟 ll 萎 l 謇羹 交量曼 奢 h s h ；i i ； 量 哮 妻 一一=2 l ii 誉 囊善 羹 女；l l； i ； hh 辞甚 萋蕴嘉蒙 蓉薹 薹 磊 薹薹囊纂 l室 薹 丞 詈萼菩誉=善 昌 日 叠蓉篁鬈 _。= n 1 研发进展 基站研发阶段从2 0 0 2 年6 月1 日开始，完成了基站的总体设计、概要设计、代码编 写以及板卡设计制版工作，至2 0 0 3 年1 月1 7 日完成预集成测试，历时约7 5 个月。研发 整体进展情况与基准计划基本匹配，各里程碑阶段均按时完成，并提交相应的可交付物。 2 测试进展 基站从2 0 0 3 年1 月2 0 日开始联调测试，至2 0 0 3 年8 月3 1 日完成系统测试。按照最 初计划，基站白箱、黑箱测试2 0 0 3 年4 月3 0 日对系统集成发布l o a d l 版本。5 月3 0 日 白箱、黑箱联合发布实体测试l o a d 2 版本。实际执行情况，白箱、黑箱测试准时发布 l o a d l 版本，对于l o a d 2 版本，5 月3 0 日以后根据产品需求调整，基站新增特性1 2 个，实 体测试增加补充测试阶段，顺延至2 0 0 3 年6 月3 0 日，l o a d 2 版本提交延迟1 个月。版本 递交准时率和版本发布通过率均达到1 0 0 。 由于实体测试阶段的调整，系统集成、系统测试顺延至2 0 0 3 年7 月3 1 日。截至 2 0 0 3 年8 月3 1 日，完成现场测试。 3 生产进展 截至2 0 0 3 年5 月3 0 日，共生产整机1 5 台。下面对具体生产情况进行分析。 ( 1 ) 生产进度符合性 生产进度符合性的统计，是从生产任务下达至整机发货、接收的整个生产周期内对各 相关环节的执行进度情况的汇总，根据各项任务的计划安捧与完成的实际情况加以对比， 分析发生问题的原因，并为避免同类问题再次发生给出建议。 从进度的情况来看，主要有两方面的问题影响生产的总体进度：生产文件的提交延 迟及文件变更；物料齐套时间延迟。本次生产文件原计划于2 0 0 3 年1 月2 0 日提交，但因 各种原因，部分板卡的提交时间有所延迟，给生产准备带来了一定困难。另外，因采购进 度及生产文件变更引起的物料齐套时间的延迟，也给保证生产按计划执行带来困难。 鉴于以上反映出的问题，为保证生产活动能够按计划顺利进行，对其中的关键环节应 加以严格约束；生产任务单下发、生产计划制定、生产文件提交及设计变更、物料齐套时 问限定、生产启动、发货时间及发货质量。其中，对于内部可控的环节，需要通过提高生 产文件的提交质量来保证后续各环节的顺利进行。同时，需要加强物料采购的管理，保证 物料齐套时问符合生产计划。 ( 2 ) 生产文件符合性 生产文件符合性统计，主要是对于提交的生产制造文件的版本变化情况加以汇总，考 察生产文件版本的一致性。下表所示为板卡名称及对应的生产版本。 版本 板卡名称 展初版本生产用版本最终版本 a 板卡 v 1 o lv l0 2v 11 0 b 板卡 v 1o 】v 10 2v 1 1 0 c 板卡 v 1o lv 10 1v 10 l d 板卡 v 10 0v 10 lv 1 0 l e 板卡 v 10 0 v 10 0 v 1 0 0 f 板# v l0 0v 1o ov 10 0 g 板卡 v 10 0v 10 2v 10 3 h 板卡 v 10 1v l0 1v 1 0 1 i 板卡 v 10 0v 10 0v 1 0 0 j 板卡 v 1 0 0v 10 0v 1 0 0 9 k 板# v 1 0 1v 10 2v 10 2 j 板卡 v 10 1 v l0 2v 10 2 m 扳卡 v 】0 0 v 10 iv l0 l n 板卡 v 1o ov 10 lv 10 1 0 板卡 v l0 lv l0 1v l0 2 p 板卡 v 10 1v l0 1v lo l q 板卡 v l0 0v 1o l v 1 ，o l ( 表2 ) 通过表2 可以看出，c 、f 、i 、j 板卡的制造文件稳定性较高，a 、b 板卡的制造文件变 化稍显频繁。制造文件的变化对于生产制造的准备、物料采购和库存都会产生一定的影 响，因此，建议研发人员在设计过程中加强同各部门的沟通，提高研发阶段的测试水平 及时发现、解决研发测试过程中出现的问题，从而保证提交生产制造文件的质量，避免因 设计不稳定所引发的文件变更给生产过程带来的不便。 根据以上问题的反馈及分析，应对项目各环节的工作有侧重点地提高和加强： 第一是研发：加强设计过程中的物料选型、评估工作；加强研发过程中的工艺审核； 提高研发过程中的测试质量；保证生产制造文件的可生产性。 第j ：是采购：加强采购活动中的货期控制；加强物料的来料检验。 第三是生产：严格控制贴装工艺，提高板卡贴装质量；严格控制装配工艺；加强出厂 检验，保证设备的成品率。 摄后是管理：应该细化各环节的进度计划，充分考虑生产、采购等过程的时间安捧； 加强资源协调、信息跟踪，实时协助解决问题。 希望通过各部门的密切配合和自身能力的提高，及时发现存在的问题，认真分析问题 的原因，有效地解决问题、排除困难，保证今后生产制造工作的顺利开展。 4 变更统计 项目进行自2 0 0 2 年6 月1 日至2 0 0 3 年8 月3 1 日，进度计划变更5 次，其中一级里 程碑变更1 次，二级里程碑变更1 次。 一级里程碑变更是2 0 0 3 年2 月1 日提交变更申请申请增加1 2 个新特性，研发阶段 周期从2 0 0 3 年2 月2 5 日至3 月3 1 日，同时延长测试计划至2 0 0 3 年6 月3 0 日。 二级里程碑变更是2 0 0 3 年5 月2 7 日提交变更申请，增加现场测试计划。 由项目的进度计划和各阶段里程碑的完成情况。以及两次二级以上里程碑变更可以看 出以下几个问题： ( 1 ) 从项目进度计划看，基站需求分析约历时1 个月，总体设计约0 5 个月，概要设 计2 个月，详细设计历时4 个月。概要设计和详细设计时间远远超过需求分析和总体设计 时间。项目加长总体设计和概要设计时间，适当缩短详细设计时间。只有前期充分评估才 能明确项目需求，避免后期对于项目范围的反复变更。 ( 2 ) 联调测试从2 0 0 3 年1 月2 0 日开始，至2 0 0 3 年8 月3 1 日完成现场测试，测试周 期约7 2 个月，是研发周期的近2 倍。导致这个问题的原因大致如下：产品在设计阶段不 够充分，遗留了很多问题。同时研发人员对测试阶段存有依靠思想，使得测试过程中发现 很多本该在研发阶段解决的问题，测试周期远远超过预期。项目需求有所调整，期间增加 了1 2 个特性，实体测试增加了补充测试，使得测试周期加长。 ( 3 ) 项目需求在其间发生了多次变化，导致项日范围也发生了较大变化，主要是由于 项目初期评估不充分、需求调研时问过短导致。项目范围的变化在必然导致了进度、预 算、人力资源等各项计划的变更。在项目前期应充分评估项目需求，同时严格需求变更管 理。 1 0 ( 二) 质量分析 1 特性实现分析 基站测试从2 0 0 3 年1 月2 0 日至2 0 0 3 年8 月3 1 日，历时约7 2 个月。基本特性1 0 9 个，后根据产品需求调整，增加新特性1 2 个，共提交特性1 2 1 个，全部完成测试，提交 率为1 0 0 。 具体提交情况如表3 所示 指标项 数值 所占比例差异分析 完全提交特性数 “79 6 7 带限提交特性数 43 t 3 因为测试条件不具备，少量用例难 以构造而没有测试。 未按时提交特性数 oo ( 表3 ) 2 测试用例分析 基站实体测试共分为两个部分，即白箱测试和黑箱测试。测试用例情况如表4 所示。 测试总用例数为2 0 5 8 个，测试通过2 0 0 5 个通过比例为9 7 a 2 。因设计小合理、条件 不具备或设计重复而废弃的用例为4 0 个，占总用例数的1 9 4 。在用例设计的过程中， 要尽可能提高用例设计的可行性，尽可能减少因设计不合理、设计重复等原因而引发的用 例废弃。 用例具体执行情况如图3 所示： 关键测试普通测试总测试用 测试用例状态 用例数目用例数日例数目 测试通过 5 4 81 4 5 72 0 0 5 未执行测试 o4 4 部分通过o22 测试未通过 o4 4 废弃 2 3 84 0 冻结 o 33 总计5 5 01 5 0 82 0 5 8 测试用例通过比例 9 9 6 4 9 6 6 2 9 7 4 2 ( 表4 ) ( 图3 ) 1 1 3 测试用例覆盖情况分析 关键测试用例数目普通测试用例数目总测试用例数目 l 测试通过用例数 5 4 81 4 5 72 0 0 5 l 用例总计 5 5 0 1 5 0 82 0 5 8 i 测试用例通过率 9 9 6 4 9 6 6 2 9 7 4 2 ( 表5 ) 表5 所示为测试用例覆盖情况，关键测试用例通过率为9 9 6 4 ，其中2 个用例因设 计不合理导致没有达到1 0 0 ，去除这两个2 个不合理用例，关键测试用例通过率可达 1 0 0 。普通测试用例通过率为9 6 6 2 ，大于9 5 。综合考虑可得出，基站测试覆盖性满 足要求。 4 b u g 情况分析 截至2 0 0 3 年8 月3 1 日，基站共提交b u g 5 2 3 个，已关闭5 0 9 个，关闭率为9 7 3 。 以下将从几个方面分析b u g 情况。 ( 1 ) b u g 趋势分析 表6 所示为基站自联调测开始至测试结束每周新增b u g 数量，其中2 0 0 3 年1 月2 0 日之前的b u g 数景为集成测试期间产生的b u g 每周新增b u g 数量统计 统计阶段新增b u g 数量 2 0 0 3 年1 月2 0 日以前 1 5 2 0 0 3 - 1 2 1 2 0 0 3 1 2 41 8 2 0 0 3 - 1 - 2 5 2 0 0 3 - l - 3 l1 5 2 0 0 3 - 2 - l 一2 0 0 3 2 7 1 7 2 0 0 3 - 2 - 8 2 0 0 3 - 2 - 1 41 0 2 0 0 3 - 2 - 1 5 2 0 0 3 2 - 2 1 6 2 0 0 3 - 2 - 2 2 2 0 0 3 - 2 - 2 8 1 2 2 0 0 3 - 3 - l 一2 0 0 3 - 3 - 7 4 5 2 0 0 3 3 8 2 0 0 3 3 - 1 42 2 2 0 0 3 - 3 - 1 5 2 0 0 3 3 _ 2 l3 5 2 0 0 3 - 3 2 2 2 0 0 3 3 2 83 0 2 0 0 3 - 3 - 2 9 2 0 睡4 - 41 6 2 0 0 3 4 5 2 0 0 3 垂l l 1 8 2 0 0 3 - 4 - 1 2 2 0 0 3 - 4 - 1 8 1 8 2 0 0 3 - 4 - 1 9 2 0 4 2 51 3 2 0 0 3 4 2 6 2 0 0 3 - 5 - 22 2 2 0 0 3 - 5 - 3 _ 五0 0 3 - 5 - 91 6 2 0 0 3 - 5 - l o 一2 0 0 3 5 - 1 6 2 2 2 0 0 3 - 5 - 1 7 2 0 0 3 - 5 _ 2 3 2 4 2 0 0 3 - 5 - 2 4 2 0 0 3 - 5 - 3 02 2 2 0 0 3 _ s _ 3 1 2 0 0 3 - 6 - 61 8 2 0 0 3 - 6 - 7 - - 一2 0 0 徘1 31 4 2 0 0 3 - 6 - l 2 0 0 3 6 - 2 0 1 5 2 0 0 3 - 6 - 2 1 2 0 0 3 - 6 - 2 71 4 2 0 0 3 6 _ 2 8 2 0 0 3 - 8 2 0 0 3 _ 7 - 5 2 0 0 3 7 - 1 17 2 0 0 3 - 7 - 1 2 2 0 0 3 7 - 1 8 4 2 0 0 3 - 7 - 1 9 2 0 0 3 7 2 5 8 2 0 0 3 - 7 - 2 6 2 0 0 3 - 8 - 1 8 1 2 2 0 0 3 - 8 - 2 2 0 0 3 8 - 89 2 0 0 3 - 8 - 9 2 0 0 3 - 8 - 1 56 2 0 0 3 - 8 - 1 6 2 0 0 3 - 8 - 2 29 2 0 0 3 - 8 - 2 3 2 0 0 3 - 8 - 3 l 7 总计 5 2 3 ( 表6 ) ( 图4 ) 按照每周新增b u g 数量统计，可以绘制出b u g 趋势图( 图4 ) ，由趋势图可以看 出，b u g 总体呈现收敛状态，但趋势并不明显。 实体测试于2 0 0 3 年3 月1 日正式开始，因此2 0 0 3 年3 月期间，b u g 提交数量呈现 峰值。2 0 0 3 年5 月b u g 数量小幅增加，其中7 5 的b u g 为“设备中试”阶段发现。这 是因为新生产的基站陆续投入测试后，系统测试大规模展开，致使b u g 数量增加。2 0 0 3 年6 月问，b u g 提交数量有所下降，是因为实体测试基本完成，中试因为没有足够的设 备，测试未正式启动。由此可以初步判断因测试任务不均衡和测试设备到位情况导致测试 过程不稳定。 ( 2 ) b u g 过程控制分析 根据以上的每周新增b u g 数量表，可以绘制出过程控制图( 图5 ) 。 1 3 ( 图5 ) 由x 图可以看出，第8 点超出上限，这正是实体测试刚刚开始的阶段，2 0 0 3 年3 月 1 日至3 月7 日b u g 数量迅速增加，之后一段时期内又呈减少趋势，这再次表明测试过 程不稳定。 由x 图可以看出，第2 2 个点至第3 3 个点( 2 0 0 3 年6 月7 日至2 0 0 3 年8 月3 1 日) ， 一共1 2 个点。均在中心线的同一侧，表示测试过程不达标准。o 参照实际情况，2 0 0 3 年7 月，基站实体测试和系统集成、系统测试测试基本完成，后续测试因缺少适当配置的基站 暂停下来，故这一阶段b u g 数量较少。8 月份新生产的基站逐步投入测试后，设备中试 测出的b u g 数量小幅增加。 由上面的分析可以看出，在项目初期应做好项目所需设备资源计划，设备使用前，项 目经理应及时盘查所需设备资源是否足够，当设备资源不能到位时及时上报风险，以便在 现有资源基础上组织调配，避免出现测试不均衡的现象。 ( 3 ) b u g 子系统分布统计 我们将b u g 按照所在的子系统划分出来，可以看出哪些子系统的出现的b u g 最 多。同时可以统计出各个子系统的万行代码b u g 数目。这一指标对于我们衡量各子系统 的代码合格率十分重要。图6 所示为b u g 子系统分布情况： ( 图6 ) o 过程控制图七点法则：如果过程某段时间内，连续七个或七个以上观察点均落在均值的同一 侧，或者连续七点持续上升，下降，那么即使它们在控制线内，也是非随机坂因引起的，即 不是一种正常的随机性偏差，而是一种系统性偏差，需要引起重视，找出根源并采取措施予 以消除，否则很可能会导致过程失控。 1 4 表7 为子系统分布统计结果，可以看出子系统a 、b 、c 包含b u g 数最多，占b u g 总数的5 2 9 6 。下表为万行代码包含的b u g 统计，平均万行代码所包含的b u g 数约为 3 4 2 。 万行代码所包平均万行代码所 子系统名称 b u g 数日 代码行数 含的b u g 数包含的b u g 数 a1 4 5 1 2 6 7 4 0 1 1 4 4 b8 2 9 8 3 7 0 83 4 c5 0 4 5 7 8 9 1 l0 9 d3 2 2 6 8 3 5 8 1 ，1 93 4 1 8 4 e3 0 1 8 6 7 4 6 1 6 l f2 5 9 2 7 5 8 2 7 0 g 1 8 1 8 2 8 4 5 o 9 8 ( 表7 ) ( 4 ) b u g 状态统计分析 b u g 状态统计如表8 所示，其中b u g 总数为5 2 3 个，未解决的b u g 为3 个( 即状 态为t d b ) 。b u g 解决率达到9 9 2 3 ，达到预期目标。图7 为根据该表绘制出的b u g 状 态统计图。 状态数量 所占百分比 f i x e d9 2 t b d3 1 n e e d m o r e i n f o8 2 d u p l i c a t e d 3 1 c i o s e d5 0 0 9 6 ( 表8 ) ( 图7 ) ( 5 ) b u g 严重程度统计 表9 为b u g 严重程度的统计，其中b u g 总数为5 2 3 个，已关闭5 0 0 个，关闭率为 9 6 ，大于8 5 雕j 目标值，满足要求。但可以看出，状态为c r i t i c a l 和m a j o r 的b u g 关闭 率均未达到1 0 0 ，未达到标准。未关闭的b u g 状态为f i x e d 和n e e d m o r e i n f o ，这需要在 1 5 后期测试中进一步定位解决。图8 和图9 是b u g 严重程度统计和b u g 关闭率统计图。 目前状态 b u g 状态b u g 数量 c l o s e df l x e dn e e d m o r e i n f od u p l i c a t e dr e j e c t e dt b d 关闭率 c r i t i c a l 4 0 3 7 l00o09 3 m a j o r 1 8 51 7 355ooo9 4 a v e r a g e 2 3 82 3 5l22o39 9 m i n o r5 24 82llo09 2 e n h a n c e m e n t87oo0008 8 总计5 2 35 0 0983039 6 ( 表9 ) ( 图8 ) ( 图9 ) 1 6 ( 6 ) b u g 问题原因分布统计 我们按照2 0 8 0 法则对b u g 问题的原因分类进行分析，绘制出帕累托图o ，可以清楚 地看到造成缺陷的8 0 问题原因所在。 由表l o 可以看出编码缺陷、设计缺陷、因修改而引入的缺陷、接口缺陷、需求分析 缺陷的累计百分比为8 0 5 9 。分析这几类缺陷原因，不难看出在设计过程、编码过程管 理、需求管理、版本升级管理方面存在漏洞，控制措施要从这几方面入手。为了加强编码 过程控制，我们制定了代码走查规范；为了加强设计过程控制，制定了技术评审实 施细则；为了加强需求管理，公司组织成立了需求管理组，从组织和流程上保证需求管 理。对于因修改而引入的缺陷，公司及项目内部逐步加强设计变更管理。通过以上过程改 进，力求促进产品质量。 b u g 问题原因数量b u g 累计数量b u g 累计百分比 1 编码缺陷 2 0 52 0 54 6 2 8 2 设计缺陷 5 82 6 35 9 3 7 3 因修改而引入的缺陷 4 3 3 0 66 9 0 7 4 接口缺陷 2 8 3 3 47 54 0 5 需求分析缺陷 2 3 3 5 78 05 9 6 外来输入缺陷 1 73 7 48 44 2 7 器件缺陷 1 63 9 08 80 4 8 性能缺陷 1 34 0 39 09 7 9 因修改| i 引起的缺陷 94 1 29 3 o o l o 生产工艺缺陷 94 2 19 5 0 3 1 1 板卡设计缺陷 6 4 2 79 6 3 9 1 2联编打包缺陷 4 4 3 l9 7 2 9 1 3 用户界面缺陷 4 4 3 59 8 1 9 1 4 结构缺陷 34 3 89 8 8 7 1 5 测试工具缺陷 34 4 l9 95 5 1 6 测试用例缺陷 l4 4 29 97 7 1 7协议理解错误 l 4 4 3l o o 0 0 总计4 4 3 ( 表1 0 ) 。帕累托图：帕累托图是按照发生频率大小顺序绘制的直方图，表示有多少结果是由已确认类 型或范畴的原因所造成。按等级排序的目的是指导如何采取纠正措施项目组应首先采取 项目组应首先采取措施纠正造成最多数量缺陷的问题。从概念上说，帕累托图与帕累托法则 一脉相承，该法则认为相对来说数量较少的原因往往造成绝大多数的问题或缺陷。此项法则 往往称为2 0 - 8 0 法则，即百分之八十的问题是百分之二十的原因所造成的。 1 7 ( 图t o ) ( 注：b u g 问题属性为n o v a l u e 的有8 0 个，本次统计未包括这部分b u g 。) ( 三) 成本分析 在讨论过项目进度情况、质量情况之后，接下来就要分析衡量项目执行的另一重要指 标成本。我们将从预算执行情况、资产占用情况、人力投入情况和代码规模、文档规 模几个方面进行分析。 1 预算执行分析 ( 1 ) 预算分布情况 项目立项时，基准预算1 8 0 0 万元。项目执行期间，由于计划变更引起了预算变化， 截至2 0 0 3 年8 月3 1 日，项目实际预算为1 7 5 0 万元。预算分布情况如表l l 所示： 固定资产研发耗材整机 生产费用其他 合计 项目立项基准 预算 5 , 8 0 0 ，0 0 0 0 03 , 0 0 0 ，0 0 0 0 08 ，4 2 0 ，0 0 00 0 7 1 5 0 0 00 06 5 0 0 0 0 0 1 8 0 0 0 , 0 0 00 0 截至2 0 0 3 8 3 1 预算 4 ，9 0 0 ，0 0 0 0 04 , 0 0 0 ，0 0 0 0 08 , 4 2 0 ，0 0 00 0 4 0 0 0 0 0 01 4 0 0 0 0 0 0 1 7 ，5 0 0 ，0 0 0 0 0 ( 表1 1 ) 图1 1 为项目基准预算与截至2 0 0 3 年8 月3 1 日预算的比较，其中整机预算没有发生 变化，其余各类预算中。生产费用大幅减少，研发耗材和其他类费用则有所增加。生产费 用的减少主要是由于项目初期基站多为公司自主生产，生产费用全部由项目支出。到了项 目后期公司转变了模式，与他公司合作生产整机，使得生产费用预算大大减少，为项目节 省了大量成本。固定资产方面，公司从节约成本的角度考虑，重新对现有的固定资产进行 1 8 盘点。按照项目优先级，在各项目间重新调配，充分利用现有设备，减少了不必要的采 购。研发耗材和其他预算有所增加，主要由于项目进行期间增加了新的特性。为了满足新 的特性及测试需求，增加了耗材等预算。 ( 图1 1 ) 下面我们从另一个角度来总结截至2 0 0 3 年8 月3 1 日预算分布情况。图1 2 为项目预 算分布情况，项目预算中，整机所占比例最大，达到4 8 1 1 。固定资产所占比例2 8 处 于中等水平，这是由于从公司方面较大力度的控制了项目的固定资产采购，减少不必要的 浪费。生产费用由于公司战略调穆仅占所有预算的0 2 3 。 ( 图1 2 ) ( 2 ) 预算执行情况 公司为了保证项目预算申请更具合理性，将项目预算执行率作为衡量项目执行情况的 一个指标。在此我们按照项目在2 0 0 3 年8 月3 1 日时的预算为基础分析预算执行情况。基 站开发过程，预算总体执行率约为9 4 7 4 。按照预算分类统计出的预算执行情况，具体 见表1 2 ： i 固定资产研发耗材整机生产费用其他 合计 l 预算值4 ，9 0 0 ，0 0 00 04 ，0 0 0 ，0 0 00 08 ，4 2 0 ，0 0 00 04 0 ，0 0 00 0 1 4 0 0 0 00 0 1 7 5 0 0 ，0 0 00 0 i 执行值4 。5 0 0 ，0 0 00 03 ，5 0 0 ，0 0 00 08 ，4 2 0 ，0 0 0 0 0 4 0 0 0 00 01 2 0 0 0 00 0 1 6 ，5 8 0 ，0 0 0 0 0 l 预算执行率9 1 8 4 8 75 0 1 0 0o o 1 0 0 0 0 8 57 1 9 47 4 ( 表1 2 ) 1 9 ( 图1 3 ) 从图1 3 中可以直观地看出各类预算执行情况的比较，其中整机预算执行率达到 1 0 0 。固定资产预算执行率为9 1 8 4 ，主要是由于项甘执行期间。公司严格控制固定资 产采购，在各项目中充分调配仪器设备，因此部分固定资产费用也在预算中删除，预算执 行率未达到1 0 0 。 2 固定资产占用情况分析 项目的资产折旧情况如表1 3 所示。其中研发阶段为明确的基站项目占用资产，进入 系统集成以后，由于测试涉及到多个项目、多个实体，这一阶段基站项目占用的所有资产 按照全部资产的1 ，3 核算。从图1 4 中可以更为清楚地看出各阶段资产占用趋势。 瑚 折1 日值、 研发系统测试合计 2 0 0 3 年5 月以前累计折| 日值2 5 8 3 5s ，2 l2 6 6 5 6 2 0 0 3 年6 月以前累计折旧值2 8 7 9 9l i 8 92 9 9 8 8 2 0 0 3 年7 月以前累计折旧值3 1 2 1 l1 5 7 53 2 t 8 6 2 0 0 3 年8 月以前累计折旧值3 3 5 6 12 1 1 43 5 6 7 5 ( 单位t 万元)( 表1 3 ) ( 图1 4 ) 2 0 由上述数据可以看出。资产折旧值每月递增数量相对稳定，这表明随项目进展由研发 到测试阶段，项目中的资产并没有体现出明显的释放过程，由图上不难看出资产都在被项 目维持续使用。然而在实际开发过程中发现，有些项目资产长期被闲置，没有充分加以利 用，造成一定的资源浪费。作为公司最重要的项目之一，大量资产归属于基站项目，项目 组在成本控制方面意识较差也是造成这一问题的重要原因。成本是衡量一个项目执行情况 的重要指标，大量资产的占用势必使项目背负很多不必要的成本，因此及时释放不需要的 资产是至关重要的。 3 人力投入分析 ( 1 ) 按阶段分析人力投入情况 基站立项计划投入人力9 0 0 人月，实际投入1 0 6 5 人月。按照里程碑阶段进行统计， 计划与实际投入人员情况如下表所示。( 说明：表1 4 中实际投入人月情况一栏，实体测 试、系统集成、系统测试数据均包括研发人员支持测试的工作量。) 研发人员对各测试阶 段支持的工作量经过估算产生，2 0 0 3 年3 月至8 月，研发人员总工作量的1 , 3 视为测试支 持。 里程碑阶段计划投入实际投入 产品总体设汁 55 概要设计2 52 5 详细设计5 0 04 5 0 预集成测试2 02 3 实体测试 7 02 7 5 系统集成 4 8l o o 系统测试 3 58 0 现场测试2 53 0 样机生产2 21 9 q e 测试 1 0 08 管理5 05 0 总计9 0 01 0 6 5 ( 单位。人月)( 表1 4 ) ( 图1 5 ) 2 1 由图1 5 中可以看出，实际人力投入曲线出现两次高峰，分别是详细设计阶段和实体 测试阶段。项目研发阶段人力实际投入情况基本与计划投入相符，这一阶段项目的进度情 况也与基准计划相符。进入实体测试阶段后，人力投入显著增加，这一方面由于研发人员 花费相当多的时间支持测试工作，这是研发设计阶段不够充分所致：另一方面经产品线调 整，基站增加了一系列新的特性，各阶段测试时间均有所增加所致。q e 测试人员预计 1 0 0 人月，实际仅投入8 人月，这主要是由于公司战略调整。q e 测试转由其他公司承 担，从而减少了项目组人员投入 ( 2 ) 人员投入分布情况 上面分析了按里程碑阶段划分的项目人力投入情况，接下来进一步分析基站项目中按 照研发、测试、生产、管理几大部分划分的人力投入状况。如前所述，项目计划投入9 0 0 人员，实际投入1 0 6 5 人月。其中研发部门预计投入6 5 0 人月，实际投入8 6 2 人月，这一 方面由于前期研发存在问题较多，过度依赖后期测试，造成测试阶段需要的研发人员支持 仍然很多，无法从项目中释放。另一方面是前面已经阐述过的原因，因为项目增加了新的 特性，造成研发人员投入大于计划需求。研发、测试、生产，管理人员分布情况及投入偏 差如下表所示： 计划投入实际投入投入偏差 研发 6 5 08 6 23 26 2 实体测试( 白箱、黑箱测试) 4 86 02 50 0 中试测试 3 06 61 2 0 0 0 样机生产 2 21 91 3 6 4 q e 测试 1 0 089 2 0 0 管理 5 05 00 0 0 ( 单位。人月)( 表1 5 ) ( 图1 6 ) 4 代码规模分析 基站项目代码总行数为1 4 6 4 5 7 5 行。各子系统分布情况如表1 6 ： 子系统有效代码行 a1 2 6 7 4 0 b9 8 3 7 0 c4 5 7 8 9 l d 2 6 8 3 5 8 e1 8 6 7 4 6 f9 2 7 5 8 g1 8 2 “5 h1 5 6 3 2 i1 1 6 8 6 j 1 1 3 1 5 k1 2 2 3 4 ( 表1 6 ) 我们可以据此估算工作效率。工作效率= 1 4 6 4 5 7 5 ( 1 0 6 5 6 0 。, * 2 0