【正文】 成情況，適當(dāng)?shù)恼{(diào)整每一個(gè)較小的階段的任務(wù)量和完成的任務(wù)時(shí)間，這種方式非常有利于整個(gè)項(xiàng)目計(jì)劃的動(dòng)態(tài)調(diào)整。也利于項(xiàng)目質(zhì)量保證的實(shí)施。 實(shí)際運(yùn)作中，當(dāng)質(zhì)量保證小組發(fā)現(xiàn)計(jì)劃實(shí)施的差異后，報(bào)告項(xiàng)目經(jīng)理，由項(xiàng)目經(jīng)理組織負(fù)責(zé)對(duì)計(jì)劃進(jìn)行周期性維護(hù)，對(duì)于已經(jīng)變動(dòng)的計(jì)劃由質(zhì)量保證小組協(xié)助配置管理小組完成版本控制。 需求分析是開發(fā)人員對(duì)系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗(yàn)來(lái)看，這個(gè)過程往往是個(gè)循序漸進(jìn)的過程，一次性對(duì)系統(tǒng)形成完整的認(rèn)識(shí)是困難的。只有不斷地和客戶領(lǐng)域?qū)＜疫M(jìn)行交流確認(rèn)，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時(shí)犯下的錯(cuò)誤，會(huì)在接下來(lái)的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時(shí)犯下的錯(cuò)誤所花費(fèi)的代價(jià)越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。 解決系統(tǒng)分析錯(cuò)誤的方法。通常采用邀請(qǐng)用戶參與進(jìn)行需求評(píng)定，然后對(duì)其用戶的意見由質(zhì)量保證成員跟蹤檢測(cè)是否納入需求規(guī)格說明書，同時(shí)與用戶簽字確認(rèn)形成需求基線，交由配置管理員放入配置管理庫(kù)。 雖然盡早的邀請(qǐng)用戶參與，仍然避免不了項(xiàng)目進(jìn)行中用戶的需求變更請(qǐng)求。對(duì)于開發(fā)過程存在的需求變動(dòng)，我們要求用戶填寫變更申請(qǐng)單發(fā)送給項(xiàng)目配置管理員，在通過配置管理員轉(zhuǎn)交質(zhì)量保證小組，負(fù)責(zé)組織專家小組和項(xiàng)目組成員一起討論實(shí)施變更的可行性及實(shí)施后所帶來(lái)的影響，小的變更則直接記錄入變更記錄原因分析項(xiàng)和風(fēng)險(xiǎn)項(xiàng)欄，大的變更則需要形成正式的變更報(bào)告，無(wú)論那種變更都需要對(duì)相應(yīng)的文檔實(shí)施同步變更（包括需求規(guī)格說明書、詳細(xì)設(shè)計(jì)文、安裝手冊(cè)、操作手冊(cè)等）。但是對(duì)于無(wú)法實(shí)現(xiàn)或是變更會(huì)帶來(lái)巨大的影響而將導(dǎo)致進(jìn)度的延期，這時(shí)，我們將變更報(bào)告提交給用戶或邀請(qǐng)用戶進(jìn)行協(xié)調(diào)會(huì)議，討論變更取舍問題或是項(xiàng)目進(jìn)度變更問題。 決定變更之后，由項(xiàng)目經(jīng)理組織實(shí)施變更，測(cè)試人員檢測(cè)變更結(jié)果，而質(zhì)量保證小組成員監(jiān)督變更實(shí)施過程并協(xié)助配置管理員對(duì)變更后的成果物進(jìn)行版本控制。變更實(shí)施完后，上線前還需要指定人員協(xié)助用戶一同測(cè)試并由用戶簽字后同意方可上線。 優(yōu)良的體系結(jié)構(gòu)應(yīng)當(dāng)具備可擴(kuò)展性和可配置性，而好的體系結(jié)構(gòu)則需要好的設(shè)計(jì)方法，自然設(shè)計(jì)選型成為了系統(tǒng)設(shè)計(jì)首要的工作，究竟是采用哪種設(shè)計(jì)方法好呢？ 對(duì)于設(shè)計(jì)選型不能一概而論，需要針對(duì)項(xiàng)目的結(jié)構(gòu)、項(xiàng)目的特征和用戶的需求來(lái)分析，同樣也要考慮到參與項(xiàng)目小組成員的素質(zhì)，如果其中大部分都沒有從事過面向?qū)ο蟮脑O(shè)計(jì)且項(xiàng)目進(jìn)對(duì)緊迫，這樣沒有多余的時(shí)間來(lái)培訓(xùn)小組成員來(lái)掌握面向?qū)ο蟮脑O(shè)計(jì)方法，盡管眾所周知面向?qū)ο笤O(shè)計(jì)方法的優(yōu)勢(shì)，我們還是不如采用面向過程的方式（除用戶指定開發(fā)設(shè)計(jì)方式外）可以減少項(xiàng)目承擔(dān)的技術(shù)風(fēng)險(xiǎn)。 公司有過一個(gè)項(xiàng)目，用戶指定需要采用面向?qū)ο蠓治觥⒃O(shè)計(jì)和開發(fā)，且開發(fā)周期短，在無(wú)奈的情況下，項(xiàng)目小組只能選用面向?qū)ο蟮能浖_發(fā)過程，由于項(xiàng)目小組很少?gòu)氖逻^面向?qū)ο蟮拈_發(fā)，經(jīng)驗(yàn)缺乏，導(dǎo)致項(xiàng)目上馬后項(xiàng)目進(jìn)度延誤，項(xiàng)目沒有達(dá)到預(yù)期的效果。 針對(duì)此次開發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對(duì)于新技術(shù)互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導(dǎo)致工作重復(fù)性高，滯后項(xiàng)目進(jìn)度。建議解決方法是項(xiàng)目組成員采用集中辦公，分塊學(xué)習(xí)，學(xué)習(xí)的成果馬上向項(xiàng)目相關(guān)人員發(fā)布，再由配置管理員對(duì)其發(fā)布的文檔進(jìn)行整理、歸類放入配置庫(kù)以供大家共享。這樣方便大家的互相學(xué)習(xí)，減少重復(fù)的工作。在這次開發(fā)中我們公司從管理人員、設(shè)計(jì)人員到開發(fā)人員都汲取了很多教訓(xùn)，同時(shí)經(jīng)過此次項(xiàng)目的開發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_發(fā)經(jīng)驗(yàn)。 除設(shè)計(jì)選型，還有一個(gè)容易被忽視的問題，就是公共類開發(fā)。公共類開發(fā)可以減少工作中的重復(fù)工作，降低開發(fā)成本。這要求我們?cè)僭O(shè)計(jì)階段通過對(duì)用戶需求的仔細(xì)研究，盡可能的識(shí)別出公共類，并進(jìn)行定義指定專人負(fù)責(zé)設(shè)計(jì)通知其它設(shè)計(jì)人員，以減少重復(fù)工作。對(duì)于項(xiàng)目組提供的設(shè)計(jì)文檔，由質(zhì)量保證小組組織技術(shù)專家、項(xiàng)目組設(shè)計(jì)人員、開發(fā)人員和測(cè)試人員對(duì)其設(shè)計(jì)文檔的評(píng)審，檢測(cè)設(shè)計(jì)文檔對(duì)其下一階段工作的可行性，及時(shí)發(fā)現(xiàn)設(shè)計(jì)中可能存在的錯(cuò)誤，降低項(xiàng)目開發(fā)風(fēng)險(xiǎn)，同時(shí)確保設(shè)計(jì)文檔能為開發(fā)人員、測(cè)試人員提供切實(shí)的指導(dǎo)。對(duì)于可復(fù)用的設(shè)計(jì)進(jìn)行提取作為公共庫(kù)設(shè)計(jì)和開發(fā)，提供項(xiàng)目組或整個(gè)公司重用。最后交由配置管理員進(jìn)行設(shè)計(jì)文檔的版本控制。 實(shí)現(xiàn)也就是代碼的生產(chǎn)過程。這里不僅包括代碼的產(chǎn)生，同時(shí)也包括測(cè)試用例的產(chǎn)生。針對(duì)上一階段提供詳細(xì)設(shè)計(jì)，程序員開始編碼并且調(diào)試程序，測(cè)試人員則根據(jù)設(shè)計(jì)進(jìn)行測(cè)試用例的設(shè)計(jì)，設(shè)計(jì)出來(lái)的用例需要得到項(xiàng)目組成員認(rèn)可由項(xiàng)目經(jīng)理審核通過才能進(jìn)入配置庫(kù)。同時(shí)程序員調(diào)試完程序提交測(cè)試人員進(jìn)行程序正確性檢測(cè)。 測(cè)試就是對(duì)軟件產(chǎn)品的檢驗(yàn)。軟件測(cè)試的目的是根據(jù)用戶需求檢查系統(tǒng)是否符合項(xiàng)目合同與任務(wù)書規(guī)定的要求。項(xiàng)目測(cè)試分集成測(cè)試和系統(tǒng)測(cè)試，主要進(jìn)行功能測(cè)試、健壯性測(cè)試、性能－效率測(cè)試、用戶界面測(cè)試、安全性測(cè)試、壓力測(cè)試、可靠性測(cè)試、安裝/反安裝測(cè)試等活動(dòng)。測(cè)試過程通常在模擬環(huán)境中進(jìn)行。只有通過了上述全部測(cè)試的軟件，才可以稱之為符合用戶質(zhì)量要求的合格的軟件。測(cè)試活動(dòng)要盡可能覆蓋整改項(xiàng)目過程，從最初的需求到部署階段，都應(yīng)該制訂詳細(xì)的計(jì)劃并編制相應(yīng)的文檔，如測(cè)試計(jì)劃、測(cè)試用例文檔、測(cè)試報(bào)告等。通過測(cè)試活動(dòng)，盡可能早得發(fā)現(xiàn)每個(gè)階段中軟件存在的缺陷，以方便后續(xù)階段的實(shí)施。在這測(cè)試活動(dòng)過程中，我們應(yīng)該遵守一條基本原則——按照用戶需求進(jìn)行測(cè)試。我們即不能為求速度而縮短測(cè)試規(guī)模，也不能忽視用戶需求而提高測(cè)試要求?？傊磺袦y(cè)試應(yīng)該符合用戶需求。在公司，維護(hù)小組的任務(wù)一方面是保證對(duì)項(xiàng)目客戶的跟蹤服務(wù)，另一方面是確保該項(xiàng)目其它的開發(fā)人員從項(xiàng)目中盡快的解脫出來(lái)以便投入到下一個(gè)項(xiàng)目的開發(fā)中。所以通常項(xiàng)目維護(hù)小組成員主要由項(xiàng)目組的少部分開發(fā)人員承擔(dān)完成。他們不僅了解軟件的核心內(nèi)容，而且與客戶也不陌生，以便能夠以最快的速度修正錯(cuò)誤。對(duì)于一般性的錯(cuò)誤，如操作不當(dāng)?shù)纫鸬膯栴}，全部由維護(hù)小組執(zhí)行完成，但需要用戶測(cè)試確認(rèn)上線。如果較大的修改則需要走變更控制流程，用戶或者維護(hù)人員填寫變更申請(qǐng)，經(jīng)專家會(huì)議討論分析可行方案在由維護(hù)小組實(shí)施，通過測(cè)試后方可提交用戶。 維護(hù)小組的人員基本上是按項(xiàng)目跟進(jìn)的。當(dāng)一個(gè)項(xiàng)目剛剛交付用戶時(shí)，在維護(hù)小組有較多的人員進(jìn)行跟進(jìn)，隨軟件的穩(wěn)定，跟進(jìn)的人逐步減少，并轉(zhuǎn)移到其它項(xiàng)目中去。文檔維護(hù)主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。 內(nèi)部文檔包括：項(xiàng)目開發(fā)計(jì)劃；需求分析；體系結(jié)構(gòu)設(shè)計(jì)說明；詳細(xì)設(shè)計(jì)說明；構(gòu)件索引；構(gòu)件成分說明；構(gòu)件接口及調(diào)用說明；組件索引；組件接口及調(diào)用說明；類索引；類屬性及方法說明；測(cè)試報(bào)告；測(cè)試統(tǒng)計(jì)報(bào)告；質(zhì)量監(jiān)督報(bào)告；源代碼；文檔分類版本索引；軟件安裝打包文件。 外部文檔主要包括：軟件安裝手冊(cè)；軟件操作手冊(cè)；在線幫助；系統(tǒng)性能指標(biāo)報(bào)告；系統(tǒng)操作索引。如何保證文檔的全面性，使其真正為項(xiàng)目的進(jìn)度提供保證，又不因?yàn)槲臋n的寫作而耽誤項(xiàng)目的進(jìn)度，這仍然是一個(gè)比較難解決的問題。解決此問題，其核心仍然是個(gè)度的問題。在本項(xiàng)目的開發(fā)中，配置管理小組的一個(gè)非常重要的任務(wù)還是書寫文檔規(guī)范和文檔模板。當(dāng)有文檔模板后需要書寫文檔的人員只剩下填空的工作，從某種意義上講，書寫文檔的速度會(huì)加快。如果書寫文檔的人員認(rèn)為文檔的更細(xì)致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時(shí)文檔并不算被正式提交，當(dāng)他人書寫完畢之后，必須由文檔的初寫者進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。 配置管理小組真正核心的工作是對(duì)文檔的組織管理。根據(jù)文檔的不同，文檔的來(lái)源也不同，有些是通過質(zhì)量保證小組經(jīng)過復(fù)審之后轉(zhuǎn)交給配置管理小組，有些則會(huì)直接從文檔的出處到達(dá)配置管理小組。文檔的管理是一個(gè)非常煩瑣的工作，但是長(zhǎng)遠(yuǎn)來(lái)看它不僅使項(xiàng)目的開發(fā)對(duì)單個(gè)主要人員的依賴減少，從而減少人員流動(dòng)給項(xiàng)目的帶來(lái)的風(fēng)險(xiǎn)，更重要的是在項(xiàng)目進(jìn)行到后百分之十的時(shí)候起到拉動(dòng)項(xiàng)目的作用。 從以往做大項(xiàng)目的經(jīng)驗(yàn)來(lái)看，寫作文檔在項(xiàng)目開發(fā)的早期可能會(huì)使項(xiàng)目的進(jìn)度比起不寫文檔要稍慢，但隨著項(xiàng)目的進(jìn)展，各個(gè)部門需要配合越來(lái)越多，開發(fā)者越來(lái)越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進(jìn)。一個(gè)明顯的例子就是系統(tǒng)整合，或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎(chǔ)之上時(shí)，就更顯現(xiàn)出文檔交流的準(zhǔn)確性和高效性。 34參考文獻(xiàn)參考文獻(xiàn)[1] 質(zhì)量管理體系 要求/中華人民共和國(guó)國(guó)家質(zhì)量監(jiān)督檢驗(yàn)疫總局、中國(guó)國(guó)家標(biāo)準(zhǔn)化管理委員會(huì)發(fā)布. —北京：中國(guó)標(biāo)準(zhǔn)出版社出版發(fā)行 ，[2] GB/T 190002000 idt ISO 9000: 2000質(zhì)量管理基礎(chǔ)教程 質(zhì)量管理體系基礎(chǔ)認(rèn)證提高 / 余取民, 余醛宏編著.—北京 : 機(jī)械工業(yè)出版社, 2003 [3] 軟件工程導(dǎo)論（第5版）/張海藩 編著—北京：清華大學(xué)出版社，[4] 項(xiàng)目管理知識(shí)體系指南（第4版）（PMBOK指南）/（美）項(xiàng)目管理協(xié)會(huì)　編著，王勇，張斌譯.—北京：電子工業(yè)出版社 ，[5] 基于CMMI的軟件工程教程/張萬(wàn)軍，儲(chǔ)善忠 編著.—北京：清華大學(xué)出版社；北京交通大學(xué)出版社，[6] 軟件質(zhì)量保證和管理/朱少民 編著.—北京：清華大學(xué)出版社，[7] 未雨綢繆：理解軟件配置管理 / 董越 編著. —北京：電子工業(yè)出版社 ，[8] 軟件測(cè)試技術(shù)大全：測(cè)試基礎(chǔ)、流行工具、項(xiàng)目實(shí)戰(zhàn)/陳能技 編著.—北京：人民郵電出版社，[9] 軟件質(zhì)量管理實(shí)踐——軟件缺陷預(yù)防、清除、管理實(shí)用方/于波，姜艷　編著—北京：電子工業(yè)出版社 ，[10] 自動(dòng)化軟件測(cè)試/張瑾，杜春暉編著.—北京：機(jī)械工業(yè)出版社，[11] 質(zhì)量工具簡(jiǎn)單講/ 李鋒，朱仲華　主編. —北京：電子工業(yè)出版社 ，[12] 軟件項(xiàng)目管理案例教程/韓萬(wàn)江 等編著.—北京：機(jī)械工業(yè)出版社，