一個項目實際開發(fā)的得與失

1、一個項目實際開發(fā)的得與失 作者簡介：我所從事的公司是一家國內(nèi)通訊公司，在“巨大中華“之內(nèi)，去年獲得了很好的業(yè)績。我本人也有 三年程序開發(fā)經(jīng)驗，有三年系統(tǒng)方案設(shè)計經(jīng)驗，對項目管理、CMM、6SIGMA等都有較深體會，做過 6SIGMA綠帶項目，完成多個系統(tǒng)總體方案的設(shè)計工作。下面以一個我曾經(jīng)做過的一個項目開發(fā)為例， 談談其成功和不到的地方，與大家共勉和交流。摘要：本文主要描述了一個實際項目的研發(fā)過程，反映了當前國內(nèi)項目的開發(fā)之現(xiàn)狀，有些經(jīng)驗， 有些感慨一項目背景我們公司有一個市場非常好的產(chǎn)品（通信產(chǎn)品），目前全國使用人數(shù)大約在300萬左右，去年該 產(chǎn)品的銷售業(yè)績是20個億以上。但是在2002/1

2、月，物料采購部門給我們發(fā)出預警機制，部分源器 件將會提停產(chǎn)，涉及單板達10多種，公司物料儲備時間是7個月。當時市場銷售形勢非常不錯，產(chǎn) 總立刻給我們項目下了任務，必須在6個月內(nèi)完成新產(chǎn)品的開發(fā)，替換已有停產(chǎn)的產(chǎn)品，屆時無法 推出新產(chǎn)品的話，我們的損失將達到數(shù)億，因此時間是非常緊急的，項目組必須在第一時間內(nèi)開發(fā) 出穩(wěn)定高效的產(chǎn)品。另外這個項目和有些項目不是完全一樣，一是產(chǎn)品的需求功能比較清晰，屬于替換型產(chǎn)品。二 是該產(chǎn)品是通信系統(tǒng)級產(chǎn)品，有著通信系統(tǒng)行業(yè)特點，復雜，穩(wěn)定性可靠性要求高。二項目成員的組織結(jié)構(gòu)我們公司采用的人員結(jié)構(gòu)是矩陣世管理，項目經(jīng)理是項目的核心，項目下有一些系統(tǒng)工程師，主 要負責

3、系統(tǒng)方案、分系統(tǒng)方案的設(shè)計工作。開發(fā)經(jīng)理根據(jù)項目產(chǎn)品的分系統(tǒng)而設(shè)立，如信令組、數(shù) 據(jù)庫組，操作系統(tǒng)組，每個開發(fā)經(jīng)理管理若干開發(fā)人員，一般是3 5人。測試經(jīng)理負責項目產(chǎn)品 的測試工作，為保證測試結(jié)果的真實可靠，實際測試經(jīng)理是不由項目經(jīng)理考核的，而是由測試部部 長進行考核，這有助產(chǎn)品測試的獨立和客觀。項目的總?cè)藬?shù)規(guī)模在40人左右。作為部門或產(chǎn)品的共用平臺，還有和項目保持獨立的產(chǎn)品輔助人員，SQA、SPEG人員、這些人員主 要負責產(chǎn)品研發(fā)過程、每個工作產(chǎn)品的交付是否符合公司的CMM規(guī)范，如系統(tǒng)方案的同行評審工作 是否正常（事實上由于進度原因，項目組和SQA人員一直處于較為對立的狀態(tài)，呵呵，只能由上層

4、 領(lǐng)導都來調(diào)解），產(chǎn)品管理經(jīng)理負責進度的監(jiān)控，開發(fā)部長提供人員、管理等方面的保障。三系統(tǒng)方案設(shè)計階段3. 1選定硬件平臺我們項目產(chǎn)品的硬件平臺是一個比較復雜的通信產(chǎn)品，其硬件單板有二十種左右，器件停產(chǎn)需要改 版的要10多種，考慮到硬件開發(fā)的周期太長，根本無法在幾個月內(nèi)搞定，必須要找現(xiàn)成的硬件平臺， 很幸運，因為公司是大公司，可用的硬件平臺比較多，可供選擇的有兩三個，前期主要是系統(tǒng)設(shè)計 人員進行硬件平臺的選型工作。這段工作非常重要，它決定了我們以后能否在短時間內(nèi)迅速開發(fā)的 先決條件。因為時間是項目的最大制約因素，同時通信產(chǎn)品的最大特點是產(chǎn)品的穩(wěn)定性，如果時間 上能在最短時間內(nèi)能開發(fā)成功，那么也就

5、是系統(tǒng)方案采取了最為有利于系統(tǒng)穩(wěn)定的方案。如果系統(tǒng) 不能快速收斂穩(wěn)定，時間上就無從談起。因此首先要對各個系統(tǒng)硬件平臺進行軟件移植的工作量評估，為了能迅速有效的進行工作量評估， 我們確定了以下幾個措施：1針對每個硬件平臺，確定各個分系統(tǒng)要移植的工作難點和工作量，分別在網(wǎng)管、數(shù)據(jù)庫、信令、 操作系統(tǒng)等各方面列出各自的難點和移植工作量，同時確定影響系統(tǒng)的最為關(guān)鍵的幾個分系統(tǒng)，信 令、操作系統(tǒng)和數(shù)據(jù)庫。2針對每個硬件平臺進行功能可擴展性、硬件穩(wěn)定性可靠性、性能指標的評估。最終花了一個月的時間確定了硬件平臺，所選擇的硬件平臺是基于系統(tǒng)能最快的穩(wěn)定、在性能和可 擴展以及可靠性等多方面的折衷的考慮。在選硬件

6、平臺中，和不同項目、不同產(chǎn)品的交流是非常有作用，溝通無極限，往往一天交流的信息 量是自己獨立看文檔的三倍，而且在一次次的交流溝通中就逐漸清晰了系統(tǒng)構(gòu)架，系統(tǒng)難點的解決 方案。3. 2確定軟件需求規(guī)格說明書在確定本需求規(guī)格說明書時和產(chǎn)品SQA人員發(fā)生了較大的沖突，按照軟件需求開發(fā)流程中，其需求 開發(fā)有以下過程。本項目并非是新項目的開發(fā)，因此對需求獲取、分析都不存在問題，但按照公司 要求，必須要編寫詳細的編寫詳細的需求規(guī)格說明，每個需求從用戶需求-系統(tǒng)需求-軟件需求 都需要編號，每項需求必須可跟蹤，在總體方案，分系統(tǒng)設(shè)計方案、詳細設(shè)計方案進行跟蹤，并且 每線需求成為測試用例用戶文檔的權(quán)威輸入性文檔

7、。在項目的實際開發(fā)中，深深體會到，羅馬不是 一天造成的，對于以前積累的相對很少的項目而言，根本無法達到這些要求，如果達到這些要求， 我和國外公司的同學交流，像我們項目這種規(guī)模，其完善的軟件需求規(guī)格說明書必須達到300-500 項左右，最后SQA人員向我們妥協(xié)，最終我們的需求規(guī)格只有30項左右，其中功能項只有15項， （好像說不過去啊，挺復雜的一個通信系統(tǒng)，將來其用戶群要達到幾百萬用戶的，我們的優(yōu)勢在于 我們都是經(jīng)驗豐富系統(tǒng)開發(fā)人員，對系統(tǒng)需求有著明確的理解，最后才沒有出現(xiàn)需求嚴重變更的情 況，）性能項10項，另外還有擴展型等其他需求。這就是中國公司軟件開發(fā)現(xiàn)狀，往往規(guī)范讓位于市場，因為首先要生

8、存，首先要賺錢我們公司不敢 說最好，至少是國內(nèi)一流，可以說代表了國內(nèi)現(xiàn)狀。3. 3工作量評估確定工作量采用了寬帶DELPHI方法，各個分系統(tǒng)進行軟件規(guī)模的估算，從軟件規(guī)模估算的結(jié)果可以看到系統(tǒng)方案的傾向性，因為網(wǎng)管是 后臺程序，其穩(wěn)定性的重要程度不如系統(tǒng)控制前臺，我們采取了寧改后臺不改前臺的方針，系統(tǒng)快 速穩(wěn)定是前提阿，不然推向市場不被用戶罵死啊？！l項目的最終工作量估算結(jié)果為5200人日。l項目的前臺的代碼規(guī)模為105138 LOC。l項目的后臺網(wǎng)管部分的代碼規(guī)模為248120 LOC3. 4分系統(tǒng)方案和詳細設(shè)計方案的設(shè)計項目進展到這個階段又和SQA人員發(fā)生嚴重沖突，因為系統(tǒng)方案還在評審階段

9、，詳細設(shè)計方案也初 步出來了，SQA人員按照的是項目的普遍規(guī)則，而我們項目則遵循的迭帶式開發(fā)模式。因為功能需 求從系統(tǒng)人員到開發(fā)人員都比較清楚，雖然不盡如意，但總體方向沒有錯。測試人員在詳細設(shè)計方案之后，開始編寫測試用例，估計則是目前最為通常的做法，還做不到軟件 需求規(guī)格說明出來之后就能寫測試用例。這個階段共完成研制規(guī)范，軟件需求規(guī)格說明書，總體方案、硬件總體、軟件總體，各詳細設(shè)計文 檔共計35份。四編程和測試微軟的測試工程師和開發(fā)工程師接近1： 1，微軟測試模式通常是開發(fā)工程師當天完工的帶碼就生成 一個當天的版本，馬上由專門的測試工程師進行測試，這樣能快速的收斂。國內(nèi)還做不到，一般而 言是1

10、： 5，因此國內(nèi)測試工程師絕大部分是黑箱測試，白盒測試都是由開發(fā)工程師自己完成或者相 互白盒測試。項目開發(fā)過程中，有二個重大改進。改進之一：以前項目通常的開發(fā)流程是項目組需要完成幾乎所有功能的總版本，測試人員才開始介 入，但這種方式每個測試周期長，產(chǎn)品錯誤收斂慢。為此，我們項目做了改進，雖然做不到一天一 個版本，但是一個星期一個版本總是可以的，而且采取了迭代開發(fā)模式，完成一個功能就生成一個 版本，馬上由測試人員進行功能性測試。這樣周期性非常之快，錯誤能得到迅速的發(fā)現(xiàn)。例如通信 系統(tǒng)最核心的功能是基本話音呼叫，就是主叫、被叫，漫游等呼叫。完成主被叫功能后就提交版本 進行相關(guān)功能測試。改進之二：發(fā)

11、現(xiàn)錯誤之后，之前一般都是由相關(guān)的系統(tǒng)人員，開發(fā)人員進行故障定位，而且這時的 故障非常多，如果每個故障都要上故障管理流程，如CQ，就非常低效，但如果每個故障不加管理， 那每個故障就只能散落在各個系統(tǒng)人員，開發(fā)人員的郵箱里，沒有統(tǒng)一的說明，其他人員也看不到， 項目組采用了一個非常好的方法，在公司特意申請了一個一個項目故障論壇，有測試人員或者開發(fā) 人員發(fā)現(xiàn)故障后，就在故障論壇上在相應的版本號下發(fā)布，所有針對該故障的解決方案都在下面跟 貼，這樣解決非常迅速，高效。這樣在前期一個月的測試過程中，共解決了 135個故障，大大收斂了故障率，隨后正式的測試過程 中，對每個故障都走CQ故障管理流程。五版本發(fā)布經(jīng)過項目組共同努力，終于如約在2002/6月份發(fā)布工作產(chǎn)品，開始第一個試驗局，效果非常理想。 而且原有產(chǎn)品確實也停產(chǎn)了，由于我們產(chǎn)品及時發(fā)布，避免了公司重大損失。我們項目的各階段開發(fā)時間表系統(tǒng)設(shè)計通過系統(tǒng)設(shè)計評審2002-01-15 - 2002-02-31詳細設(shè)計/編程通過詳細設(shè)計和完成編程2002-03-1 - 2002-5-30制造聯(lián)試通過成果鑒定2002-6-1 - 2002-7-