項(xiàng)目管理的質(zhì)量保證計劃
作者: 來源: 文字大小:[大][中][小]
項(xiàng)目管理的保證
項(xiàng)目管理的主要目標(biāo)是保證項(xiàng)目在規(guī)定時間內(nèi)高質(zhì)量的完成項(xiàng)目。項(xiàng)目管理包括了項(xiàng)目組開發(fā)各階段的人員結(jié)構(gòu)的配置，質(zhì)量控制的實(shí)施方略，內(nèi)部文檔和產(chǎn)品文檔的組織編寫等各項(xiàng)工作。
開發(fā)項(xiàng)目按照規(guī)范化軟件的生產(chǎn)方式進(jìn)行生產(chǎn)，在生產(chǎn)流程上采用ISO9000的標(biāo)準(zhǔn)進(jìn)行。項(xiàng)目開發(fā)參與的角色有項(xiàng)目經(jīng)理，項(xiàng)目負(fù)責(zé)人，領(lǐng)域?qū)＜遥到y(tǒng)分析員，程序員，測試組，技術(shù)支持部，質(zhì)量監(jiān)督組，文檔組。下面就各個角色一一說明其主要職責(zé)。
項(xiàng)目經(jīng)理
主要負(fù)責(zé)該項(xiàng)目開發(fā)商在開發(fā)和維護(hù)的過程中同客戶的商務(wù)接洽和開發(fā)配合方面的事物，包括：項(xiàng)目合同的簽定；提交開發(fā)計劃給客戶； 組織客戶與分析人員進(jìn)行需求確定； 組織客戶階段性驗(yàn)收； 協(xié)調(diào)客戶提供測試環(huán)境； 監(jiān)督項(xiàng)目進(jìn)度與質(zhì)量； 提供開發(fā)人員所需的各種人力物力資源； 負(fù)責(zé)項(xiàng)目開發(fā)過程中客戶、開發(fā)項(xiàng)目組、質(zhì)量監(jiān)督部，文檔組等相關(guān)部門的聯(lián)絡(luò)與溝通。
項(xiàng)目的開發(fā)采用項(xiàng)目負(fù)責(zé)人責(zé)任制。項(xiàng)目的開發(fā)由項(xiàng)目負(fù)責(zé)人全權(quán)負(fù)責(zé)，負(fù)責(zé)的范圍包括： 項(xiàng)目開發(fā)計劃的制定； 開發(fā)方法的確定； 技術(shù)規(guī)范的編制； 項(xiàng)目各階段的人員配給與人員之間的配合； 各階段文檔的生成和版本編號。
領(lǐng)域?qū)＜?nbsp;
主要責(zé)任是協(xié)同系統(tǒng)分析員認(rèn)清領(lǐng)域邊界，確定領(lǐng)域內(nèi)容。領(lǐng)域?qū)＜铱梢杂煽蛻舫檎{(diào)技術(shù)骨干擔(dān)任，也可以由開發(fā)商聘請擔(dān)任。領(lǐng)域?qū)＜以陂_發(fā)過程中主要參與的階段是系統(tǒng)需求分析，在明確了系統(tǒng)將來要完成的主要任務(wù)之后，領(lǐng)域?qū)＜业穆氊?zé)轉(zhuǎn)向系統(tǒng)用戶界面的確定上。開發(fā)出的系統(tǒng)能被客戶接受的兩個重要指標(biāo)一個是系統(tǒng)正確性，即系統(tǒng)是否正確的完成了用戶希望它完成的任務(wù)；第二就是系統(tǒng)操作的便捷性。便捷主要受到使用系統(tǒng)的客戶的操作習(xí)慣的制約。領(lǐng)域?qū)＜彝嵌嗄陱氖略擁?xiàng)工作的人員，他們的使用習(xí)慣會對系統(tǒng)的易用性非常有幫助。領(lǐng)域?qū)＜覅⑴c的開發(fā)階段受到開發(fā)方式的影響。
系統(tǒng)分析員
系統(tǒng)分析員是系統(tǒng)開發(fā)方法的貫徹者和系統(tǒng)實(shí)現(xiàn)的指導(dǎo)者。分析人員主要參與開發(fā)階段的需求分析和系統(tǒng)設(shè)計兩個階段（這兩個階段并不是截然分開的，由開發(fā)方式的不同，可能會貫穿整個開發(fā)工期）。
首先系統(tǒng)分析員和領(lǐng)域?qū)＜乙黄饘︻I(lǐng)域進(jìn)行分析，確定領(lǐng)域邊界和領(lǐng)域內(nèi)容。在完成這項(xiàng)任務(wù)后，系統(tǒng)分析員應(yīng)當(dāng)提交《系統(tǒng)需求報告》。《系統(tǒng)需求報告》由領(lǐng)域?qū)＜掖_認(rèn)之后交給質(zhì)量監(jiān)督組進(jìn)行復(fù)審，復(fù)審?fù)戤呌晌臋n組進(jìn)行文檔規(guī)范化，進(jìn)行存檔和版本編號，與此同時，規(guī)范化的《系統(tǒng)需求報告》由項(xiàng)目經(jīng)理轉(zhuǎn)交給客戶進(jìn)行復(fù)審（項(xiàng)目經(jīng)理對《系統(tǒng)需求報告》的內(nèi)容格式等有審查的義務(wù)）。
客戶復(fù)審?fù)戤呏笸ㄟ^項(xiàng)目負(fù)責(zé)人轉(zhuǎn)交給系統(tǒng)分析員進(jìn)行更新修正，并對版本進(jìn)行升級。之后再經(jīng)質(zhì)量監(jiān)督組和文檔組等環(huán)節(jié)進(jìn)行流轉(zhuǎn)，直到該報告無須進(jìn)行再流轉(zhuǎn)為止。 接下來系統(tǒng)分析員的一項(xiàng)主要任務(wù)是對領(lǐng)域進(jìn)行分析和映射，構(gòu)造系統(tǒng)構(gòu)架，即進(jìn)行體系結(jié)構(gòu)的設(shè)計。
參與的系統(tǒng)分析員在不止一個時，首先由分析員委員會進(jìn)行體系結(jié)構(gòu)設(shè)計，當(dāng)體系結(jié)構(gòu)基本確定之后，定義分組和分組之間的接口，特別對將來需要密切接口的部分要進(jìn)行詳細(xì)定義，包括彼此間的"通訊協(xié)議"，時間及方式等等。完成該項(xiàng)工作后必須產(chǎn)生《體系結(jié)構(gòu)設(shè)計說明》。《體系結(jié)構(gòu)設(shè)計說明》生成后由項(xiàng)目負(fù)責(zé)人提交給質(zhì)量監(jiān)督組進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^之后，由文檔組進(jìn)行格式化和版本編號并存檔。《體系結(jié)構(gòu)設(shè)計說明》的完整流轉(zhuǎn)過程在開發(fā)商內(nèi)部，客戶并不介入。
程序員
為了有效的利用領(lǐng)域?qū)＜业馁Y源，在體系結(jié)構(gòu)設(shè)計的同時，可以由系統(tǒng)分析員的指導(dǎo)之下，由程序員進(jìn)行界面原形的開發(fā)。界面原形由領(lǐng)域?qū)＜疫M(jìn)行評審。評審?fù)ㄟ^后由客戶進(jìn)行復(fù)審。界面原形跳過質(zhì)量監(jiān)督由文檔組進(jìn)行格式化和存檔。質(zhì)量監(jiān)督有了解和監(jiān)督界面原形變化的責(zé)任。 程序員參與系統(tǒng)詳細(xì)設(shè)計，主要負(fù)責(zé)系統(tǒng)的實(shí)現(xiàn)工作，并對測試組提供相應(yīng)的測試資源。由于詳細(xì)設(shè)計的詳細(xì)程度不易把握，有程序員參與的情況下，系統(tǒng)分析人員與程序員的交流會有助于系統(tǒng)開發(fā)進(jìn)度。在項(xiàng)目代碼生產(chǎn)的后期，程序員要進(jìn)行相應(yīng)的白盒測試。之后，可執(zhí)行體提交到測試組進(jìn)行測試。《系統(tǒng)詳細(xì)設(shè)計說明》由分析員和程序員共同完成。通過項(xiàng)目負(fù)責(zé)人轉(zhuǎn)交質(zhì)量監(jiān)督組進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^后，由文檔組進(jìn)行格式化和版本編號，并存檔。
測試組
主要進(jìn)行軟件的測試工作。上面提到程序員在交給測試人員之前是進(jìn)行過一定的白盒測試的。測試人員根據(jù)詳細(xì)設(shè)計的文檔對軟件要實(shí)現(xiàn)的功能進(jìn)行一一測試，保證軟件的執(zhí)行體正確的實(shí)現(xiàn)設(shè)計要求，在此也只證明了軟件正確的反映了設(shè)計思想，但是否真正反映了用戶的需求仍需要進(jìn)一步的測試。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本項(xiàng)目中占有重要的地位，性能要求有可能改變軟件的設(shè)計，為避免造成軟件的后期返工，測試在性能上需要較大的側(cè)重。
同樣，測試在不同的階段需要不同的"輸入"與"輸出"。在正確性測試階段，不需要太詳細(xì)的測試計劃和測試策略的設(shè)計。而在性能測試時，需要分析人員提出測試策略和測試用例，質(zhì)量監(jiān)督組同樣會提出他們認(rèn)為必要的測試策略和測試用例，后者提出的測試策略和測試用例被認(rèn)為是對前者的抽樣調(diào)查。無論是前者還是后者提出的測試策略和測試用例，都由測試組組織實(shí)施。
質(zhì)量監(jiān)督組
保證軟件透明開發(fā)的主要環(huán)節(jié)。在項(xiàng)目開發(fā)的過程中幾乎所有的部門都與質(zhì)量監(jiān)督組有關(guān)。質(zhì)量監(jiān)督組對項(xiàng)目經(jīng)理提供項(xiàng)目進(jìn)度與項(xiàng)目真正開發(fā)時的差異報告，提出差異原因和改進(jìn)方法。在項(xiàng)目進(jìn)度被延滯或質(zhì)量監(jiān)督組認(rèn)為某階段開發(fā)質(zhì)量有問題時，提請項(xiàng)目經(jīng)理、項(xiàng)目負(fù)責(zé)人等必要的相關(guān)人員舉行質(zhì)量會議。解決當(dāng)前存在的和潛在的問題。質(zhì)量監(jiān)督是建立在文檔的復(fù)審基礎(chǔ)之上，因而文檔版本的控制，特別是軟件配置管理，直接影響軟件質(zhì)量監(jiān)督的影響力和力度。文檔組則是保證軟件質(zhì)量監(jiān)督的得以實(shí)施的重要保證。
質(zhì)量監(jiān)督組的監(jiān)督范圍包括： 系統(tǒng)分析人員是否正確的反映了用戶的需求； 軟件執(zhí)行體是否正確的實(shí)現(xiàn)了分析人員的設(shè)計思想； 測試人員是否進(jìn)行了較為徹底的和全面的測試； 文檔組是否對文檔的規(guī)范化進(jìn)行的比較徹底，版本控制是否有效；
文檔組
是保證項(xiàng)目開發(fā)完畢的同時，內(nèi)部文檔和外部文檔都同時完成。內(nèi)部文檔的及時產(chǎn)生和規(guī)范，是保證項(xiàng)目開發(fā)各小組能夠更好的接口和溝通的重要前提，從另一個方面講，也是保證工程不被某個關(guān)鍵路徑所阻塞而延滯的前提。如上所述，文檔組還是保證質(zhì)量監(jiān)督組得以發(fā)揮作用的基礎(chǔ)。
文檔組的主要職責(zé)包括： 完善各個部門發(fā)送需要存檔和進(jìn)行版本控制的文檔； 對文檔進(jìn)行單向出入的控制； 對所有存檔的文檔進(jìn)行版本控制； 書寫文檔規(guī)范，并傳達(dá)到開發(fā)組中； 書寫部分外部文檔。
技術(shù)支持部
技術(shù)支持部的存在是保證軟件在用戶使用的過程中，為用戶提供最及時的技術(shù)服務(wù)，也為項(xiàng)目開發(fā)人員抽身進(jìn)行新版本軟件開發(fā)保證。技術(shù)支持部的人員能夠作到對軟件的使用人員進(jìn)行軟件的安裝、配置、正確使用進(jìn)行培訓(xùn)。能夠解決由于軟件的不當(dāng)使用產(chǎn)生的各種問題。技術(shù)支持部的人員也有對軟件系統(tǒng)分析監(jiān)督的作用。技術(shù)支持人員是軟件開發(fā)過程中的虛擬用戶，也就是說在軟件未正式提交用戶之前，技術(shù)支持人員充當(dāng)用戶的角色。
合作伙伴提供的保證
軟件的開發(fā)我們選用微軟公司的Windows平臺和Visual Studio為主要開發(fā)工具。 我公司是微軟（Microsoft）在中國最大的技術(shù)方案提供商，在軟件開發(fā)方面能夠直接從微軟公司獲得最快最全面的技術(shù)支持。另一方面，公司能最快速的獲得微軟最新的企業(yè)解決方案的培訓(xùn)和咨詢。同時我公司還是微軟出版社中國唯一總代理，公司擁有微軟最全面的書面資訊。
項(xiàng)目進(jìn)度的保證
項(xiàng)目進(jìn)度是項(xiàng)目進(jìn)行是否順利的最直觀表現(xiàn)。顯然在項(xiàng)目開始之前，項(xiàng)目開發(fā)計劃是必須的。如果項(xiàng)目開發(fā)計劃的制定的是完全合理的，那項(xiàng)目進(jìn)度也就真正表達(dá)了項(xiàng)目與最終的交付使用之間的距離，然而要制定完全合理的項(xiàng)目開發(fā)計劃幾乎不太可能。可見要保證項(xiàng)目進(jìn)度，首先要保證項(xiàng)目開發(fā)計劃盡可能合理。
項(xiàng)目計劃的合理程度與項(xiàng)目計劃制定者從事類似規(guī)模和類似業(yè)務(wù)的項(xiàng)目的經(jīng)驗(yàn)有直接關(guān)系，通過經(jīng)驗(yàn)往往能夠預(yù)見潛在的阻礙，從而制定較為合理的項(xiàng)目開發(fā)計劃。本公司已經(jīng)開發(fā)過鐵道部的結(jié)算系統(tǒng)，開發(fā)中的子項(xiàng)目多達(dá)六個，歷時十五個月，目前多數(shù)項(xiàng)目已經(jīng)開發(fā)完畢，有些系統(tǒng)已經(jīng)投入運(yùn)營五個月，項(xiàng)目金額數(shù)千萬元。在這樣的項(xiàng)目中，從管理者到開發(fā)人員到測試人員都積累了較為豐富的經(jīng)驗(yàn)，特別是項(xiàng)目開發(fā)計劃的制定，和項(xiàng)目進(jìn)度的控制。
項(xiàng)目計劃以里程碑為界限，將整個開發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當(dāng)?shù)恼{(diào)整每一個較小的階段的任務(wù)量和完成的任務(wù)時間，這種方式非常有利于整個項(xiàng)目計劃的動態(tài)調(diào)整。也利于項(xiàng)目質(zhì)量的監(jiān)督。
里程碑就是對項(xiàng)目在開發(fā)過程中完成的較大成果的定義，比如需求分析完畢、代碼生產(chǎn)完畢、正確性測試完畢，都被定義為一個里程碑，每一個里程碑都需要對完成的界定方式進(jìn)行定義。比如需求分析完畢為一里程碑，這一里程碑完成的定義是：《系統(tǒng)需求說明》必須經(jīng)過客戶的確認(rèn)，并在文檔組進(jìn)行了相應(yīng)的歸檔工作。當(dāng)然把完成需求分析作為里程碑不一定恰當(dāng)，因?yàn)橄到y(tǒng)開發(fā)往往伴隨著需求的不斷變化和新需求的不斷產(chǎn)生。 如此又引出新的問題，即如何定義恰當(dāng)?shù)睦锍瘫绾谓缍ɡ锍瘫耐瓿伞?里程碑將項(xiàng)目分成若干個較小的段，通過保證每一個段的順利完成，來保證整個項(xiàng)目順利完成，同時通過每個段的完成質(zhì)量，可以測度整個項(xiàng)目質(zhì)量。同時里程碑保證各個階段的產(chǎn)品的依賴關(guān)系盡可能的小，并以完備的文檔作為里程碑完成的重要標(biāo)志之一。在里程碑和完備文檔的控制之下，項(xiàng)目已完成的階段是受到保護(hù)的，在任何時間，人員變動，甚至是開發(fā)商的變動，都不至于造成特別重大的損失，通過完備的文檔，原有的成果能夠被延續(xù)進(jìn)行開發(fā)。
項(xiàng)目開發(fā)方法對項(xiàng)目質(zhì)量的保證
項(xiàng)目的開發(fā)方法對項(xiàng)目的質(zhì)量和按時完成也有較大的影響。
面向?qū)ο蟮拈_發(fā)方法有利于對問題領(lǐng)域的深入理解，也有利于將問題空間向解空間映射從而得到更加理想和完整的系統(tǒng)模型。同時面向?qū)ο蟮拈_發(fā)方法和實(shí)現(xiàn)方法也有利于系統(tǒng)錯誤被局限在較小的范圍內(nèi)，不會出現(xiàn)骨牌效應(yīng)。面向?qū)ο蟮拈_發(fā)方法也有不利的方面。開發(fā)人員對它的熟悉程度不如傳統(tǒng)的結(jié)構(gòu)化的開發(fā)方法。對面向?qū)ο笾行鲁霈F(xiàn)的名詞需要重新在開發(fā)隊(duì)伍中進(jìn)行定義，以便在開發(fā)的過程中彼此交流時表達(dá)的更加準(zhǔn)確，從而減少開發(fā)隊(duì)伍之間的通訊量。通訊量的降低意味著效率的提高，減少了占用開發(fā)時間討論一個彼此立場根本一致的"問題"的時間。軟件構(gòu)架定義了該領(lǐng)域中特定對象必然發(fā)生關(guān)系的發(fā)生方式，這種發(fā)生方式以構(gòu)架中抽象類之間定義的關(guān)系被固化在構(gòu)件中，開發(fā)人員在開發(fā)應(yīng)用系統(tǒng)時不必再為定義這種相互作用方式而書寫代碼，這為將來系統(tǒng)的維護(hù)奠定了堅(jiān)實(shí)的基礎(chǔ)，也為將來新版本軟件的透明升級并保持兼容性和正確性提供了有利保證。通過面向?qū)ο蟮睦^承特性，可以在不傷害原有系統(tǒng)的情況下，任意替換功能模塊，從而以效率更高的模塊代替原有模塊，從另一角度講，也實(shí)現(xiàn)了軟件模塊的配置功能。要實(shí)現(xiàn)真正的軟件模塊的即插即用，還需要利用面向?qū)ο蟮牧硪粌?yōu)勢--組件。
面向?qū)ο笫沟妹嫦驅(qū)ο蟮念惢驅(qū)ο罂梢砸耘c語言無關(guān)的二進(jìn)制方式被存儲和調(diào)用。這就是COM技術(shù)。顯然軟件構(gòu)架實(shí)現(xiàn)的基礎(chǔ)是COM組件。由于COM是二進(jìn)制的方式被存儲，因而它可以被任何語言編寫的軟件所調(diào)用。組件與系統(tǒng)分離，只是在發(fā)生系統(tǒng)調(diào)用時才被調(diào)入內(nèi)存執(zhí)行，這就保證了系統(tǒng)更高層次的即插即用。
鑒于如此多的好處，采用面向?qū)ο蟮募夹g(shù)進(jìn)行該項(xiàng)目的開發(fā)是值得的。
對于上面提到的面向?qū)ο蟮牟焕蛩夭捎萌缦路椒ㄟM(jìn)行克服：第一，在系統(tǒng)開發(fā)之前，首先定義技術(shù)術(shù)語，然后定義領(lǐng)域術(shù)語，這樣保證了開發(fā)過程中開發(fā)人員用同種"語言"進(jìn)行交流，避免了文不對題的討論或爭論。第二，指定技術(shù)規(guī)范。在殊途同歸的情況下，我們只允許那些在技術(shù)規(guī)范之內(nèi)的技術(shù)來實(shí)現(xiàn)。技術(shù)規(guī)范定義了若干種對象技術(shù)，這些技術(shù)規(guī)范在整個開發(fā)小組中進(jìn)行統(tǒng)一認(rèn)識方面的學(xué)習(xí)。
開發(fā)策略是針對不同開發(fā)技術(shù)和問題領(lǐng)域而作出的策略性的考慮。顯然開發(fā)策略與所用的開發(fā)方法、實(shí)現(xiàn)技術(shù)以及問題領(lǐng)域的特征密切相關(guān)。一般來講，鑒于面向?qū)ο蟮?quot;無縫"特性，采用原形法比較恰當(dāng)，而開發(fā)過程則采用螺旋式開發(fā)方法。螺旋式開發(fā)方法提高了人員的利用率，使得軟件開發(fā)的局部階段相互重疊，在整體上形成多道流水線重疊并行。顯然這又縮短了開發(fā)的總周期。
項(xiàng)目開發(fā)各階段的質(zhì)量保證
需求分析
需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗(yàn)來看，這個過程往往是個循序漸進(jìn)的過程，一次性對系統(tǒng)形成完整的認(rèn)識是困難的。只有不斷地和客戶領(lǐng)域?qū)＜疫M(jìn)行交流確認(rèn)，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費(fèi)的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。同時，想在某個時間點(diǎn)上宣布需求分析已經(jīng)完畢，不再需要進(jìn)行進(jìn)一步的需求分析，這也是不現(xiàn)實(shí)的。經(jīng)驗(yàn)告訴我們，往往在測試過程中會發(fā)現(xiàn)，用戶真正想要的并非您腦海中的設(shè)想，另一方面用戶往往知道自己肯定不需要什么，而無法明確告知他們需要的是什么。面對這些事實(shí)，我們無法期望改變用戶；比如提高用戶同分析人員的"溝通"能力，讓他們說出的話更能被分析人員理解。唯一的做法是采用一定的方式方法，誘導(dǎo)用戶盡可能早地將需求表達(dá)出來，表達(dá)得完整。
在某個項(xiàng)目中我們的做法有兩個方面：一是請領(lǐng)域?qū)＜覅⑴c到系統(tǒng)開發(fā)的早期階段；二是開發(fā)系統(tǒng)原形，原形包括功能性的原形和用戶界面性的原形，也可以是二者混合的原形，用這些原形確認(rèn)用戶的需求。讓領(lǐng)域?qū)＜覅⑴c開發(fā)的早期階段，是保證分析人員有充足的時間和領(lǐng)域?qū)＜疫M(jìn)行充分的交流和確認(rèn)。在這個階段，原形可能在提交到用戶之前，首先被領(lǐng)域?qū)＜掖_認(rèn)，這樣保證了原形被認(rèn)可的程度和認(rèn)可過程耗費(fèi)的時間盡可能的短，從而在提高效率的同時保證了質(zhì)量。
在開發(fā)方內(nèi)部還有三項(xiàng)保證措施： 系統(tǒng)分析委員會保證系統(tǒng)分析集思廣益； 質(zhì)量監(jiān)督組對分析工作的監(jiān)督； 技術(shù)支持人員參與需求調(diào)研。
分析委員會的意義在于任何分析人員在提交其所分析部分的分析說明書前，必須通過委員會的共同審議，委員會的成員根據(jù)各自的分析經(jīng)驗(yàn)和自身所分析的部分對他人的分析報告提出質(zhì)疑。如此審議過后保證了各部分間相互關(guān)聯(lián)的部分被明確定義，避免了由于"疏忽"造成系統(tǒng)在后期進(jìn)行整合時出現(xiàn)較嚴(yán)重的系統(tǒng)鴻溝或系統(tǒng)重疊。
質(zhì)量監(jiān)督組在項(xiàng)目的任何階段都要提出監(jiān)督計劃。按照監(jiān)督計劃分配相應(yīng)的資源來保證某階段的開發(fā)質(zhì)量。分析階段的監(jiān)督計劃會在分析任務(wù)之前被項(xiàng)目經(jīng)理，項(xiàng)目負(fù)責(zé)人、系統(tǒng)分析員以及技術(shù)支持所了解。為保證分析工作高質(zhì)量進(jìn)行，同時分析工作又不被過分打擾，質(zhì)量監(jiān)督組則主要針對《系統(tǒng)分析報告》進(jìn)行復(fù)審，只在認(rèn)為確實(shí)有必要的情況下才召開質(zhì)量復(fù)審會議。質(zhì)量復(fù)審會議的主要參與者是項(xiàng)目經(jīng)理、項(xiàng)目負(fù)責(zé)人、分析人員和質(zhì)量監(jiān)督組組長。會議的主要議題是提出質(zhì)量質(zhì)疑，給出改進(jìn)建議即可。具體是否存在質(zhì)量問題，是否需要改進(jìn)，不在會議中進(jìn)行討論。以此保證了會議參與的人數(shù)較少，會議的時間盡可能的短。
通過技術(shù)支持的職責(zé)可以發(fā)現(xiàn)，技術(shù)支持參與分析調(diào)研有利于對分析工作的監(jiān)督，在獲得用戶需求的口頭表達(dá)之后，能幫助技術(shù)支持更好地扮演開發(fā)階段"用戶"的角色。技術(shù)支持具有相當(dāng)?shù)挠嬎銠C(jī)技術(shù)背景，在接下來的開發(fā)過程中就能較好的起到監(jiān)督的作用，也為將來維護(hù)和為用戶提供更好的服務(wù)奠定基礎(chǔ)。
系統(tǒng)設(shè)計
優(yōu)良的體系結(jié)構(gòu)應(yīng)當(dāng)具備可擴(kuò)展性和可配置性，這兩方面因素的實(shí)現(xiàn)是通過Windows DNA的應(yīng)用完成的，正如建議書中所述，在此不再贅述。
實(shí)現(xiàn)
實(shí)現(xiàn)也就是代碼的生產(chǎn)過程。從設(shè)計的結(jié)構(gòu)圖中可以看出，生產(chǎn)的類別有類的生產(chǎn)，組件的生產(chǎn)，構(gòu)件的生產(chǎn)，應(yīng)用系統(tǒng)的整合，以及各種測試用例的生產(chǎn)。為了能夠提高生產(chǎn)的質(zhì)量，我們將生產(chǎn)的程序人員按職能分成兩組，測試用例的生產(chǎn)和測試用例生產(chǎn)，也就是說如果某個程序員生產(chǎn)了某個組件，則其測試用例不能再由該程序員來生產(chǎn)，但他可以生產(chǎn)其他組件的測試用例。這樣交叉生產(chǎn)更容易發(fā)現(xiàn)組件的存在的問題。測試人員按照測試用例來測試組件的各項(xiàng)指標(biāo)提出測試報告。
隨生產(chǎn)的不斷深入，組件的生產(chǎn)日趨減少，構(gòu)件的生產(chǎn)的量開始逐步增加，生產(chǎn)構(gòu)件的過程又是對組件的考驗(yàn)過程。因此描述組件實(shí)現(xiàn)的文檔是非常重要的，它將有可能成為阻礙進(jìn)一步生產(chǎn)的瓶頸。文檔組在生產(chǎn)過程中的重要工作是對各類部件的文檔進(jìn)行豐富和規(guī)范，同時進(jìn)行版本的控制。文檔的完備與否，在開發(fā)的后期，對項(xiàng)目進(jìn)度有至關(guān)重要的影響。文檔是共享前期開發(fā)成果的唯一手段。根據(jù)上一節(jié)描述的應(yīng)用系統(tǒng)體系結(jié)構(gòu)來看，整個開發(fā)環(huán)節(jié)絲絲相扣，每一步都受到上一步的制約。
為了控制系統(tǒng)開發(fā)過程中的往復(fù)，不至于產(chǎn)生重大過失和往復(fù)的泛濫。文檔組和質(zhì)量監(jiān)督組協(xié)同完成軟件開發(fā)的配置管理。
軟件配置管理的目的在于控制軟件開發(fā)過程中的"變化"，這種變化可能是外部引起的，如需求的變化。也可能是來自于內(nèi)部的變化，如早期設(shè)計的某個部件不夠完備，需要修改等。為了控制這些變化，把變化引起的波動盡可能的控制在有限的范圍內(nèi)。
配置項(xiàng)是指需要進(jìn)行控制的任何文檔單元，它可能是需求說明報告，也可能是需求說明報告的某個點(diǎn)。在本項(xiàng)目中需要控制的內(nèi)部配置項(xiàng)包括需求報告，設(shè)計報告，組件代碼，組件接口文檔，構(gòu)件及構(gòu)件相關(guān)文檔；外部配置項(xiàng)包括項(xiàng)目計劃書，使用手冊，系統(tǒng)安裝說明和系統(tǒng)配置說明等。
在文檔沒有被提交出開發(fā)組以前，文檔可以在開發(fā)組內(nèi)部"任意"地被修改，但一旦文檔被提交，則相關(guān)的部門就會被調(diào)動，來維護(hù)文檔的質(zhì)量。因此為了保證工作效率，開發(fā)組提交文檔之前必須慎重，以免引起不必要的工作量的增加。從另一角度來看，開發(fā)部受到嚴(yán)密的監(jiān)督，從而保證了開發(fā)的各個環(huán)節(jié)對于開發(fā)的全過程保持透明，避免了因?yàn)閭€人的原因造成整個開發(fā)的癱瘓或受阻。項(xiàng)目經(jīng)理通過質(zhì)監(jiān)報告可以了項(xiàng)目開發(fā)的進(jìn)度和質(zhì)量情況，為調(diào)整開發(fā)計劃提供有利的依據(jù)。
顯然開發(fā)部的內(nèi)部流程在配置管理的過程中受到的監(jiān)管是非常有限的。配置管理所能起的作用完全是建立在文檔之上。當(dāng)項(xiàng)目進(jìn)度非常緊張時，開發(fā)部可能書寫文檔的時間會非常少，在此情況之下質(zhì)量監(jiān)督組和文檔組就肩負(fù)將開發(fā)部提供的文檔進(jìn)行豐富和完善的工作，從而減少開發(fā)部書寫文檔的時間，當(dāng)然這是增加質(zhì)量監(jiān)督組與開發(fā)部的口頭交流為代價的。
測試
測試組的工作被分成若干階段，不同階段的劃分是以保證軟件質(zhì)量的不同指標(biāo)為目標(biāo)的。
測試的軟件指標(biāo)分別包括： 軟件的正確性：正確性測試主要是測試軟件的功能是否被正確的實(shí)現(xiàn)。 測試的方式主要是按照功能的要求按照給定的輸入，看是否有給定的輸出。在非標(biāo)稱輸入時，輸出是否異常等。一方面測試軟件的功能是否實(shí)現(xiàn)，同時是否實(shí)現(xiàn)的完整。
性能指標(biāo)：該項(xiàng)目對性能的要求非同一般的軟件項(xiàng)目。性能測試往往包含了壓力測試、攻擊性測試等測試，軟件所能承受的極限是多少，一般來將軟件的極限應(yīng)當(dāng)高出用戶要求的性能，各種指標(biāo)也應(yīng)當(dāng)為用戶所了解。
易用性：軟件的使用界面在設(shè)計實(shí)現(xiàn)的時候應(yīng)當(dāng)設(shè)法使之與功能的實(shí)現(xiàn)相脫離。脫離的原因在于易用性是通過友好的界面實(shí)現(xiàn)的。然而讓開發(fā)人員以使用者的角度來確定軟件是否易用是件非常困難的事情，在確定使用界面時往往需要多次的反復(fù)修改，甚至只能在軟件的最后交付之前或用戶使用一段時間之后才被提出來。鑒于這種特點(diǎn)，軟件在開發(fā)的不同階段都作了相應(yīng)的保證措施，比如在軟件需求界定的時候請領(lǐng)域?qū)＜覅⑴c，在軟件設(shè)計階段，讓功能的實(shí)現(xiàn)盡可能地包含在軟件的組件之中，也就是沒有界面要求的底層實(shí)現(xiàn)。界面的實(shí)現(xiàn)僅僅依賴于一個數(shù)據(jù)接口，界面僅僅負(fù)責(zé)將用戶輸入的數(shù)據(jù)送到指定的數(shù)據(jù)塊中，用于顯示的數(shù)據(jù)也在指定的數(shù)據(jù)塊中提取，只要保證數(shù)據(jù)塊被互斥的訪問就可以了。有了這樣的設(shè)計結(jié)構(gòu)，軟件的易用性也就相當(dāng)容易保證了。當(dāng)測試中發(fā)現(xiàn)易用性的問題時，軟件不會傷到筋骨，皮毛的修改總是非常容易的。
測試人員的角色也是逐步的由開發(fā)向用戶方向轉(zhuǎn)移。
測試存在兩個非常重要的問題，一是保證測試的結(jié)果真正是反映了軟件的質(zhì)量。一般來講，如果測試測出的錯誤數(shù)是收斂的情況，基本認(rèn)為測試本身應(yīng)當(dāng)是比較全面的和足夠深入的。二是測試結(jié)果的反饋。測試報告是測試結(jié)果的正式書面反饋形式。測試報需要經(jīng)過質(zhì)量監(jiān)督組的復(fù)審，并進(jìn)行統(tǒng)計，再形成質(zhì)量監(jiān)督報告的一部分，提交到項(xiàng)目經(jīng)理和項(xiàng)目開發(fā)組組長處。同時，測試組產(chǎn)生的測試報告和測試統(tǒng)計報告也要進(jìn)行歸檔，以便跟蹤軟件的質(zhì)量進(jìn)展。這也是軟件進(jìn)行版本編號的一個重要依據(jù)。
文檔維護(hù)
文檔維護(hù)主要是文檔組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。
內(nèi)部文檔包括： 項(xiàng)目開發(fā)計劃； 需求分析； 體系結(jié)構(gòu)設(shè)計說明； 詳細(xì)設(shè)計說明； 構(gòu)件索引； 構(gòu)件成分說明； 構(gòu)件接口及調(diào)用說明； 組件索引； 組件接口及調(diào)用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統(tǒng)計報告； 質(zhì)量監(jiān)督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。
外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統(tǒng)性能指標(biāo)報告； 系統(tǒng)操作索引。
文檔的重要性在前面的章節(jié)中已經(jīng)多次提到。如何保證文檔的全面性，使其真正為項(xiàng)目的進(jìn)度提供保證，又不因?yàn)槲臋n的寫作而耽誤項(xiàng)目的進(jìn)度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項(xiàng)目的開發(fā)中，文檔組的一個非常重要的任務(wù)還是書寫文檔規(guī)范和文檔模板。當(dāng)有文檔模板后需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認(rèn)為文檔的更細(xì)致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當(dāng)他人書寫完畢之后，必須由文檔的初寫者進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。
文檔組真正核心的工作是對文檔的組織管理。根據(jù)文檔的不同，文檔的來源也不同，有些是通過質(zhì)量監(jiān)督組經(jīng)過復(fù)審之后轉(zhuǎn)交給文檔組，有些則會直接從文檔的出處到達(dá)文檔組。文檔的管理是一個非常煩瑣的工作，但是長遠(yuǎn)來看它不僅使項(xiàng)目的開發(fā)對單個主要人員的依賴減少，從而減少人員流動給項(xiàng)目的帶來的風(fēng)險，更重要的是在項(xiàng)目進(jìn)行到后百分之十的時候起到拉動項(xiàng)目的作用。從以往做大項(xiàng)目的經(jīng)驗(yàn)來看，寫作文檔在項(xiàng)目開發(fā)的早期可能會使項(xiàng)目的進(jìn)度比起不寫文檔要稍慢，但隨著項(xiàng)目的進(jìn)展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進(jìn)。一個明顯的例子就是系統(tǒng)整合，或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎(chǔ)之上時，就更顯現(xiàn)出文檔交流的準(zhǔn)確性和高效性。
系統(tǒng)維護(hù)保證
對于該項(xiàng)目，軟件維護(hù)主要由公司的技術(shù)支持部來完成。技術(shù)支持在本公司的角色在第一章中已經(jīng)有所描述。在這里需要重申的是，在本公司，技術(shù)支持的任務(wù)一方面是保證對項(xiàng)目客戶的跟蹤服務(wù)，另一方面是把該項(xiàng)目的開發(fā)人員從項(xiàng)目中盡快的解脫出來以便投入到下一個項(xiàng)目的開發(fā)中，因此要求技術(shù)支持人員在項(xiàng)目開始的時候就介入其中，并在開發(fā)的過程中不斷跟蹤項(xiàng)目，特別是開發(fā)中同客戶的交流，他們必須參加。不僅如此，軟件的代碼編寫，他們也需要有所了解，并對非核心代碼能夠進(jìn)行一定的修改，最起碼能夠準(zhǔn)確定位錯誤，以便提請公司以最快的速度修正錯誤。對于一般性的錯誤，如操作不當(dāng)?shù)纫鸬膯栴}，全部由技術(shù)支持部來解決。
技術(shù)支持部的人員基本上是按項(xiàng)目跟進(jìn)的。當(dāng)一個項(xiàng)目剛剛交付用戶時，在技術(shù)支持部會有較多的人員進(jìn)行跟進(jìn)，隨軟件的穩(wěn)定，跟進(jìn)的人逐步減少，并轉(zhuǎn)移到其它項(xiàng)目中去。