一个项目实际开发的得与失

1、一个项目实际开发的得与失 作者简介：我所从事的公司是一家国内通讯公司，在“巨大中华“之内，去年获得了很好的业绩。我本人也有 三年程序开发经验，有三年系统方案设计经验，对项目管理、CMM、6SIGMA等都有较深体会，做过 6SIGMA绿带项目，完成多个系统总体方案的设计工作。下面以一个我曾经做过的一个项目开发为例， 谈谈其成功和不到的地方，与大家共勉和交流。摘要：本文主要描述了一个实际项目的研发过程，反映了当前国内项目的开发之现状，有些经验， 有些感慨一项目背景我们公司有一个市场非常好的产品（通信产品），目前全国使用人数大约在300万左右，去年该 产品的销售业绩是20个亿以上。但是在2002/1

2、月，物料采购部门给我们发出预警机制，部分源器 件将会提停产，涉及单板达10多种，公司物料储备时间是7个月。当时市场销售形势非常不错，产 总立刻给我们项目下了任务，必须在6个月内完成新产品的开发，替换已有停产的产品，届时无法 推出新产品的话，我们的损失将达到数亿，因此时间是非常紧急的，项目组必须在第一时间内开发 出稳定高效的产品。另外这个项目和有些项目不是完全一样，一是产品的需求功能比较清晰，属于替换型产品。二 是该产品是通信系统级产品，有着通信系统行业特点，复杂，稳定性可靠性要求高。二项目成员的组织结构我们公司采用的人员结构是矩阵世管理，项目经理是项目的核心，项目下有一些系统工程师，主 要负责

3、系统方案、分系统方案的设计工作。开发经理根据项目产品的分系统而设立，如信令组、数 据库组，操作系统组，每个开发经理管理若干开发人员，一般是3 5人。测试经理负责项目产品 的测试工作，为保证测试结果的真实可靠，实际测试经理是不由项目经理考核的，而是由测试部部 长进行考核，这有助产品测试的独立和客观。项目的总人数规模在40人左右。作为部门或产品的共用平台，还有和项目保持独立的产品辅助人员，SQA、SPEG人员、这些人员主 要负责产品研发过程、每个工作产品的交付是否符合公司的CMM规范，如系统方案的同行评审工作 是否正常（事实上由于进度原因，项目组和SQA人员一直处于较为对立的状态，呵呵，只能由上层

4、 领导都来调解），产品管理经理负责进度的监控，开发部长提供人员、管理等方面的保障。三系统方案设计阶段3. 1选定硬件平台我们项目产品的硬件平台是一个比较复杂的通信产品，其硬件单板有二十种左右，器件停产需要改 版的要10多种，考虑到硬件开发的周期太长，根本无法在几个月内搞定，必须要找现成的硬件平台， 很幸运，因为公司是大公司，可用的硬件平台比较多，可供选择的有两三个，前期主要是系统设计 人员进行硬件平台的选型工作。这段工作非常重要，它决定了我们以后能否在短时间内迅速开发的 先决条件。因为时间是项目的最大制约因素，同时通信产品的最大特点是产品的稳定性，如果时间 上能在最短时间内能开发成功，那么也就

5、是系统方案采取了最为有利于系统稳定的方案。如果系统 不能快速收敛稳定，时间上就无从谈起。因此首先要对各个系统硬件平台进行软件移植的工作量评估，为了能迅速有效的进行工作量评估， 我们确定了以下几个措施：1针对每个硬件平台，确定各个分系统要移植的工作难点和工作量，分别在网管、数据库、信令、 操作系统等各方面列出各自的难点和移植工作量，同时确定影响系统的最为关键的几个分系统，信 令、操作系统和数据库。2针对每个硬件平台进行功能可扩展性、硬件稳定性可靠性、性能指标的评估。最终花了一个月的时间确定了硬件平台，所选择的硬件平台是基于系统能最快的稳定、在性能和可 扩展以及可靠性等多方面的折衷的考虑。在选硬件

6、平台中，和不同项目、不同产品的交流是非常有作用，沟通无极限，往往一天交流的信息 量是自己独立看文档的三倍，而且在一次次的交流沟通中就逐渐清晰了系统构架，系统难点的解决 方案。3. 2确定软件需求规格说明书在确定本需求规格说明书时和产品SQA人员发生了较大的冲突，按照软件需求开发流程中，其需求 开发有以下过程。本项目并非是新项目的开发，因此对需求获取、分析都不存在问题，但按照公司 要求，必须要编写详细的编写详细的需求规格说明，每个需求从用户需求-系统需求-软件需求 都需要编号，每项需求必须可跟踪，在总体方案，分系统设计方案、详细设计方案进行跟踪，并且 每线需求成为测试用例用户文档的权威输入性文档

7、。在项目的实际开发中，深深体会到，罗马不是 一天造成的，对于以前积累的相对很少的项目而言，根本无法达到这些要求，如果达到这些要求， 我和国外公司的同学交流，像我们项目这种规模，其完善的软件需求规格说明书必须达到300-500 项左右，最后SQA人员向我们妥协，最终我们的需求规格只有30项左右，其中功能项只有15项， （好像说不过去啊，挺复杂的一个通信系统，将来其用户群要达到几百万用户的，我们的优势在于 我们都是经验丰富系统开发人员，对系统需求有着明确的理解，最后才没有出现需求严重变更的情 况，）性能项10项，另外还有扩展型等其他需求。这就是中国公司软件开发现状，往往规范让位于市场，因为首先要生

8、存，首先要赚钱我们公司不敢 说最好，至少是国内一流，可以说代表了国内现状。3. 3工作量评估确定工作量采用了宽带DELPHI方法，各个分系统进行软件规模的估算，从软件规模估算的结果可以看到系统方案的倾向性，因为网管是 后台程序，其稳定性的重要程度不如系统控制前台，我们采取了宁改后台不改前台的方针，系统快 速稳定是前提阿，不然推向市场不被用户骂死啊？！l项目的最终工作量估算结果为5200人日。l项目的前台的代码规模为105138 LOC。l项目的后台网管部分的代码规模为248120 LOC3. 4分系统方案和详细设计方案的设计项目进展到这个阶段又和SQA人员发生严重冲突，因为系统方案还在评审阶段

9、，详细设计方案也初 步出来了，SQA人员按照的是项目的普遍规则，而我们项目则遵循的迭带式开发模式。因为功能需 求从系统人员到开发人员都比较清楚，虽然不尽如意，但总体方向没有错。测试人员在详细设计方案之后，开始编写测试用例，估计则是目前最为通常的做法，还做不到软件 需求规格说明出来之后就能写测试用例。这个阶段共完成研制规范，软件需求规格说明书，总体方案、硬件总体、软件总体，各详细设计文 档共计35份。四编程和测试微软的测试工程师和开发工程师接近1： 1，微软测试模式通常是开发工程师当天完工的带码就生成 一个当天的版本，马上由专门的测试工程师进行测试，这样能快速的收敛。国内还做不到，一般而 言是1

10、： 5，因此国内测试工程师绝大部分是黑箱测试，白盒测试都是由开发工程师自己完成或者相 互白盒测试。项目开发过程中，有二个重大改进。改进之一：以前项目通常的开发流程是项目组需要完成几乎所有功能的总版本，测试人员才开始介 入，但这种方式每个测试周期长，产品错误收敛慢。为此，我们项目做了改进，虽然做不到一天一 个版本，但是一个星期一个版本总是可以的，而且采取了迭代开发模式，完成一个功能就生成一个 版本，马上由测试人员进行功能性测试。这样周期性非常之快，错误能得到迅速的发现。例如通信 系统最核心的功能是基本话音呼叫，就是主叫、被叫，漫游等呼叫。完成主被叫功能后就提交版本 进行相关功能测试。改进之二：发

11、现错误之后，之前一般都是由相关的系统人员，开发人员进行故障定位，而且这时的 故障非常多，如果每个故障都要上故障管理流程，如CQ，就非常低效，但如果每个故障不加管理， 那每个故障就只能散落在各个系统人员，开发人员的邮箱里，没有统一的说明，其他人员也看不到， 项目组采用了一个非常好的方法，在公司特意申请了一个一个项目故障论坛，有测试人员或者开发 人员发现故障后，就在故障论坛上在相应的版本号下发布，所有针对该故障的解决方案都在下面跟 贴，这样解决非常迅速，高效。这样在前期一个月的测试过程中，共解决了 135个故障，大大收敛了故障率，随后正式的测试过程 中，对每个故障都走CQ故障管理流程。五版本发布经过项目组共同努力，终于如约在2002/6月份发布工作产品，开始第一个试验局，效果非常理想。 而且原有产品确实也停产了，由于我们产品及时发布，避免了公司重大损失。我们项目的各阶段开发时间表系统设计通过系统设计评审2002-01-15 - 2002-02-31详细设计/编程通过详细设计和完成编程2002-03-1 - 2002-5-30制造联试通过成果鉴定2002-6-1 - 2002-7-