項目管理的保證

　　項目管理的主要目標是保證項目在規定時(shí)間內高質(zhì)量的完成項目。項目管理包括了項目組開(kāi)發(fā)各階段的人員結構的配置，質(zhì)量控制的實(shí)施方略，內部文檔和產(chǎn)品文檔的組織編寫(xiě)等各項工作。

　　開(kāi)發(fā)項目按照規范化軟件的生產(chǎn)方式進(jìn)行生產(chǎn)，在生產(chǎn)流程上采用ISO9000的標準進(jìn)行。項目開(kāi)發(fā)參與的角色有項目經(jīng)理，項目負責人，領(lǐng)域專(zhuān)家，系統分析員，程序員，測試組，技術(shù)支持部，質(zhì)量監督組，文檔組。下面就各個(gè)角色一一說(shuō)明其主要職責。

　　項目經(jīng)理

　　主要負責該項目開(kāi)發(fā)商在開(kāi)發(fā)和維護的過(guò)程中同客戶(hù)的商務(wù)接洽和開(kāi)發(fā)配合方面的事物，包括：項目合同的簽定；提交開(kāi)發(fā)計劃給客戶(hù)；組織客戶(hù)與分析人員進(jìn)行需求確定；組織客戶(hù)階段性驗收；協(xié)調客戶(hù)提供測試環(huán)境；監督項目進(jìn)度與質(zhì)量；提供開(kāi)發(fā)人員所需的各種人力物力資源；負責項目開(kāi)發(fā)過(guò)程中客戶(hù)、開(kāi)發(fā)項目組、質(zhì)量監督部，文檔組等相關(guān)部門(mén)的聯(lián)絡(luò )與溝通。

　　項目的開(kāi)發(fā)采用項目負責人責任制。項目的開(kāi)發(fā)由項目負責人全權負責，負責的范圍包括：項目開(kāi)發(fā)計劃的制定；開(kāi)發(fā)方法的確定；技術(shù)規范的編制；項目各階段的人員配給與人員之間的配合；各階段文檔的生成和版本編號。

　　領(lǐng)域專(zhuān)家

　　主要責任是協(xié)同系統分析員認清領(lǐng)域邊界，確定領(lǐng)域內容。領(lǐng)域專(zhuān)家可以由客戶(hù)抽調技術(shù)骨干擔任，也可以由開(kāi)發(fā)商聘請擔任。領(lǐng)域專(zhuān)家在開(kāi)發(fā)過(guò)程中主要參與的階段是系統需求分析，在明確了系統將來(lái)要完成的主要任務(wù)之后，領(lǐng)域專(zhuān)家的職責轉向系統用戶(hù)界面的確定上。開(kāi)發(fā)出的系統能被客戶(hù)接受的兩個(gè)重要指標一個(gè)是系統正確性，即系統是否正確的完成了用戶(hù)希望它完成的任務(wù)；第二就是系統操作的便捷性。便捷主要受到使用系統的客戶(hù)的操作習慣的制約。領(lǐng)域專(zhuān)家往往是多年從事該項工作的人員，他們的使用習慣會(huì )對系統的易用性非常有幫助。領(lǐng)域專(zhuān)家參與的開(kāi)發(fā)階段受到開(kāi)發(fā)方式的影響。

　　系統分析員

　　系統分析員是系統開(kāi)發(fā)方法的貫徹者和系統實(shí)現的指導者。分析人員主要參與開(kāi)發(fā)階段的需求分析和系統設計兩個(gè)階段（這兩個(gè)階段并不是截然分開(kāi)的，由開(kāi)發(fā)方式的不同，可能會(huì )貫穿整個(gè)開(kāi)發(fā)工期）。

　　首先系統分析員和領(lǐng)域專(zhuān)家一起對領(lǐng)域進(jìn)行分析，確定領(lǐng)域邊界和領(lǐng)域內容。在完成這項任務(wù)后，系統分析員應當提交《系統需求報告》�！断到y需求報告》由領(lǐng)域專(zhuān)家確認之后交給質(zhì)量監督組進(jìn)行復審，復審完畢由文檔組進(jìn)行文檔規范化，進(jìn)行存檔和版本編號，與此同時(shí)，規范化的《系統需求報告》由項目經(jīng)理轉交給客戶(hù)進(jìn)行復審（項目經(jīng)理對《系統需求報告》的內容格式等有審查的義務(wù)）。

　　客戶(hù)復審完畢之后通過(guò)項目負責人轉交給系統分析員進(jìn)行更新修正，并對版本進(jìn)行升級。之后再經(jīng)質(zhì)量監督組和文檔組等環(huán)節進(jìn)行流轉，直到該報告無(wú)須進(jìn)行再流轉為止。接下來(lái)系統分析員的一項主要任務(wù)是對領(lǐng)域進(jìn)行分析和映射，構造系統構架，即進(jìn)行體系結構的設計。

　　參與的系統分析員在不止一個(gè)時(shí)，首先由分析員委員會(huì )進(jìn)行體系結構設計，當體系結構基本確定之后，定義分組和分組之間的接口，特別對將來(lái)需要密切接口的部分要進(jìn)行詳細定義，包括彼此間的“通訊協(xié)議”，時(shí)間及方式等等。完成該項工作后必須產(chǎn)生《體系結構設計說(shuō)明》�！扼w系結構設計說(shuō)明》生成后由項目負責人提交給質(zhì)量監督組進(jìn)行復審，復審通過(guò)之后，由文檔組進(jìn)行格式化和版本編號并存檔�！扼w系結構設計說(shuō)明》的完整流轉過(guò)程在開(kāi)發(fā)商內部，客戶(hù)并不介入。

　　程序員

　　為了有效的利用領(lǐng)域專(zhuān)家的資源，在體系結構設計的同時(shí)，可以由系統分析員的指導之下，由程序員進(jìn)行界面原形的開(kāi)發(fā)。界面原形由領(lǐng)域專(zhuān)家進(jìn)行評審。評審通過(guò)后由客戶(hù)進(jìn)行復審。界面原形跳過(guò)質(zhì)量監督由文檔組進(jìn)行格式化和存檔。質(zhì)量監督有了解和監督界面原形變化的責任。程序員參與系統詳細設計，主要負責系統的實(shí)現工作，并對測試組提供相應的測試資源。由于詳細設計的詳細程度不易把握，有程序員參與的情況下，系統分析人員與程序員的交流會(huì )有助于系統開(kāi)發(fā)進(jìn)度。在項目代碼生產(chǎn)的后期，程序員要進(jìn)行相應的白盒測試。之后，可執行體提交到測試組進(jìn)行測試�！断到y詳細設計說(shuō)明》由分析員和程序員共同完成。通過(guò)項目負責人轉交質(zhì)量監督組進(jìn)行復審，復審通過(guò)后，由文檔組進(jìn)行格式化和版本編號，并存檔。

　　測試組

　　主要進(jìn)行軟件的測試工作。上面提到程序員在交給測試人員之前是進(jìn)行過(guò)一定的白盒測試的。測試人員根據詳細設計的文檔對軟件要實(shí)現的功能進(jìn)行一一測試，保證軟件的執行體正確的實(shí)現設計要求，在此也只證明了軟件正確的反映了設計思想，但是否真正反映了用戶(hù)的需求仍需要進(jìn)一步的測試。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。

　　同樣，測試在不同的階段需要不同的“輸入”與“輸出”。在正確性測試階段，不需要太詳細的測試計劃和測試策略的設計。而在性能測試時(shí)，需要分析人員提出測試策略和測試用例，質(zhì)量監督組同樣會(huì )提出他們認為必要的測試策略和測試用例，后者提出的測試策略和測試用例被認為是對前者的抽樣調查。無(wú)論是前者還是后者提出的測試策略和測試用例，都由測試組組織實(shí)施。

　　質(zhì)量監督組

　　保證軟件透明開(kāi)

　　提出的測試策略和測試用例，都由測試組組織實(shí)施。

　　質(zhì)量監督組

　　保證軟件透明開(kāi)發(fā)的主要環(huán)節。在項目開(kāi)發(fā)的過(guò)程中幾乎所有的部門(mén)都與質(zhì)量監督組有關(guān)。質(zhì)量監督組對項目經(jīng)理提供項目進(jìn)度與項目真正開(kāi)發(fā)時(shí)的差異報告，提出差異原因和改進(jìn)方法。在項目進(jìn)度被延滯或質(zhì)量監督組認為某階段開(kāi)發(fā)質(zhì)量有問(wèn)題時(shí)，提請項目經(jīng)理、項目負責人等必要的相關(guān)人員舉行質(zhì)量會(huì )議。解決當前存在的和潛在的問(wèn)題。質(zhì)量監督是建立在文檔的復審基礎之上，因而文檔版本的控制，特別是軟件配置管理，直接影響軟件質(zhì)量監督的影響力和力度。文檔組則是保證軟件質(zhì)量監督的得以實(shí)施的重要保證。

　　質(zhì)量監督組的監督范圍包括：系統分析人員是否正確的反映了用戶(hù)的需求；軟件執行體是否正確的實(shí)現了分析人員的設計思想；測試人員是否進(jìn)行了較為徹底的和全面的測試；文檔組是否對文檔的規范化進(jìn)行的比較徹底，版本控制是否有效；

　　文檔組

　　是保證項目開(kāi)發(fā)完畢的同時(shí)，內部文檔和外部文檔都同時(shí)完成。內部文檔的及時(shí)產(chǎn)生和規范，是保證項目開(kāi)發(fā)各小組能夠更好的接口和溝通的重要前提，從另一個(gè)方面講，也是保證工程不被某個(gè)關(guān)鍵路徑所阻塞而延滯的前提。如上所述，文檔組還是保證質(zhì)量監督組得以發(fā)揮作用的基礎。

　　文檔組的主要職責包括：完善各個(gè)部門(mén)發(fā)送需要存檔和進(jìn)行版本控制的文檔；對文檔進(jìn)行單向出入的控制；對所有存檔的文檔進(jìn)行版本控制；書(shū)寫(xiě)文檔規范，并傳達到開(kāi)發(fā)組中；書(shū)寫(xiě)部分外部文檔。

　　技術(shù)支持部

　　技術(shù)支持部的存在是保證軟件在用戶(hù)使用的過(guò)程中，為用戶(hù)提供最及時(shí)的技術(shù)服務(wù)，也為項目開(kāi)發(fā)人員抽身進(jìn)行新版本軟件開(kāi)發(fā)保證。技術(shù)支持部的人員能夠作到對軟件的使用人員進(jìn)行軟件的安裝、配置、正確使用進(jìn)行培訓。能夠解決由于軟件的不當使用產(chǎn)生的各種問(wèn)題。技術(shù)支持部的人員也有對軟件系統分析監督的作用。技術(shù)支持人員是軟件開(kāi)發(fā)過(guò)程中的虛擬用戶(hù)，也就是說(shuō)在軟件未正式提交用戶(hù)之前，技術(shù)支持人員充當用戶(hù)的角色。

　　合作伙伴提供的保證

　　軟件的開(kāi)發(fā)我們選用微軟公司的Windows平臺和VisualStudio為主要開(kāi)發(fā)工具。我公司是微軟（Microsoft）在中國最大的技術(shù)方案提供商，在軟件開(kāi)發(fā)方面能夠直接從微軟公司獲得最快最全面的技術(shù)支持。另一方面，公司能最快速的獲得微軟最新的企業(yè)解決方案的培訓和咨詢(xún)。同時(shí)我公司還是微軟出版社中國唯一總代理，公司擁有微軟最全面的書(shū)面資訊。

　　項目進(jìn)度的保證

　　項目進(jìn)度是項目進(jìn)行是否順利的最直觀(guān)表現。顯然在項目開(kāi)始之前，項目開(kāi)發(fā)計劃是必須的。如果項目開(kāi)發(fā)計劃的制定的是完全合理的，那項目進(jìn)度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開(kāi)發(fā)計劃幾乎不太可能�？梢�(jiàn)要保證項目進(jìn)度，首先要保證項目開(kāi)發(fā)計劃盡可能合理。

　　項目計劃的合理程度與項目計劃制定者從事類(lèi)似規模和類(lèi)似業(yè)務(wù)的項目的經(jīng)驗有直接關(guān)系，通過(guò)經(jīng)驗往往能夠預見(jiàn)潛在的阻礙，從而制定較為合理的項目開(kāi)發(fā)計劃。本公司已經(jīng)開(kāi)發(fā)過(guò)鐵道部的結算系統，開(kāi)發(fā)中的子項目多達六個(gè)，歷時(shí)十五個(gè)月，目前多數項目已經(jīng)開(kāi)發(fā)完畢，有些系統已經(jīng)投入運營(yíng)五個(gè)月，項目金額數千萬(wàn)元。在這樣的項目中，從管理者到開(kāi)發(fā)人員到測試人員都積累了較為豐富的經(jīng)驗，特別是項目開(kāi)發(fā)計劃的制定，和項目進(jìn)度的控制。

　　項目計劃以里程碑為界限，將整個(gè)開(kāi)發(fā)周期劃分為若干階段。根據里程碑的完成情況，適當的調整每一個(gè)較小的階段的任務(wù)量和完成的任務(wù)時(shí)間，這種方式非常有利于整個(gè)項目計劃的動(dòng)態(tài)調整。也利于項目質(zhì)量的監督。

　　里程碑就是對項目在開(kāi)發(fā)過(guò)程中完成的較大成果的定義，比如需求分析完畢、代碼生產(chǎn)完畢、正確性測試完畢，都被定義為一個(gè)里程碑，每一個(gè)里程碑都需要對完成的界定方式進(jìn)行定義。比如需求分析完畢為一里程碑，這一里程碑完成的定義是：《系統需求說(shuō)明》必須經(jīng)過(guò)客戶(hù)的確認，并在文檔組進(jìn)行了相應的歸檔工作。當然把完成需求分析作為里程碑不一定恰當，因為系統開(kāi)發(fā)往往伴隨著(zhù)需求的不斷變化和新需求的不斷產(chǎn)生。如此又引出新的問(wèn)題，即如何定義恰當的里程碑，如何界定里程碑的完成。里程碑將項目分成若干個(gè)較小的段，通過(guò)保證每一個(gè)段的順利完成，來(lái)保證整個(gè)項目順利完成，同時(shí)通過(guò)每個(gè)段的完成質(zhì)量，可以測度整個(gè)項目質(zhì)量。同時(shí)里程碑保證各個(gè)階段的產(chǎn)品的依賴(lài)關(guān)系盡可能的小，并以完備的文檔作為里程碑完成的重要標志之一。在里程碑和完備文檔的控制之下，項目已完成的階段是受到保護的，在任何時(shí)間，人員變動(dòng)，甚至是開(kāi)發(fā)商的變動(dòng)，都不至于造成特別重大的損失，通過(guò)完備的文檔，原有的成果能夠被延續進(jìn)行開(kāi)發(fā)。

　　項目開(kāi)發(fā)方法對項目質(zhì)量的保證

　　項目的開(kāi)發(fā)方法對項目的質(zhì)量和按時(shí)完成也有較大的影響。

　　面向對象的開(kāi)發(fā)方法有利于對問(wèn)題領(lǐng)域的深入理解，也有利于將問(wèn)題空間向解空間映射從而得到更加理想和完整的系統模型。同時(shí)面向對象的開(kāi)發(fā)方法和實(shí)現方法也有利于系統錯誤被局限在較小的范圍內，不會(huì )出現骨牌效應。面向對象的開(kāi)發(fā)方法也有不利的方面。開(kāi)發(fā)人員對它的熟悉程度不如傳統的結構化的開(kāi)發(fā)方法。對面向對象中新出現的名詞需要重新在開(kāi)發(fā)隊伍中進(jìn)行定義，以便在開(kāi)發(fā)的過(guò)程中彼此交流時(shí)表達的更加準確，從而減少開(kāi)發(fā)隊伍之間的通訊量。通訊量的降低意味著(zhù)效率的提高，減少了占用開(kāi)發(fā)時(shí)間討論一個(gè)彼此立場(chǎng)根本一致的“問(wèn)題”的時(shí)間。軟件構架定義了該領(lǐng)域中特定對象必然發(fā)生關(guān)系的發(fā)生方式，這種發(fā)生方式以構架中抽象類(lèi)之間定義的關(guān)系被固化在構件中，開(kāi)發(fā)人員在開(kāi)發(fā)應用系統時(shí)不必再為定義這種相互作用方式而書(shū)寫(xiě)代碼，這為將來(lái)系統的維護奠定了堅實(shí)的基礎，也為將來(lái)新版本軟件的透明升級并保持兼容性和正確性提供了有利保證。通過(guò)面向對象的繼承特性，可以在不傷害原有系統的情況下，任意替換功能模塊，從而以效率更高的模塊代替原有模塊，從另一角度講，也實(shí)現了軟件模塊的配置功能。要實(shí)現真正的軟件模塊的即插即用，還需要利用面向對象的另一優(yōu)勢——組件。

　　面向對象使得面向對象的類(lèi)或對象可以以與語(yǔ)言無(wú)關(guān)的二進(jìn)制方式被存儲和調用。這就是COM技術(shù)。顯然軟件構架實(shí)現的基礎是COM組件。由于COM是二進(jìn)制的方式被存儲，因而它可以被任何語(yǔ)言編寫(xiě)的軟件所調用。組件與系統分離，只是在發(fā)生系統調用時(shí)才被調入內存執行，這就保證了系統更高層次的即插即用。

　　鑒于如此多的好處，采用面向對象的技術(shù)進(jìn)行該項目的開(kāi)發(fā)是值得的。

　　對于上面提到的面向對象的不利因素采用如下方法進(jìn)行克服：第一，在系統開(kāi)發(fā)之前，首先定義技術(shù)術(shù)語(yǔ)，然后定義領(lǐng)域術(shù)語(yǔ)，這樣保證了開(kāi)發(fā)過(guò)程中開(kāi)發(fā)人員用同種“語(yǔ)言”進(jìn)行交流，避免了文不對題的討論或爭論。第二，指定技術(shù)規范。在殊途同歸的情況下，我們只允許那些在技術(shù)規范之內的技術(shù)來(lái)實(shí)現。技術(shù)規范定義了若干種對象技術(shù)，這些技術(shù)規范在整個(gè)開(kāi)發(fā)小組中進(jìn)行統一認識方面的學(xué)習。

　　開(kāi)發(fā)策略是針對不同開(kāi)發(fā)技術(shù)和問(wèn)題領(lǐng)域而作出的策略性的考慮。顯然開(kāi)發(fā)策略與所用的開(kāi)發(fā)方法、實(shí)現技術(shù)以及問(wèn)題領(lǐng)域的特征密切相關(guān)。一般來(lái)講，鑒于面向對象的“無(wú)縫”特性，采用原形法比較恰當，而開(kāi)發(fā)過(guò)程則采用螺旋式開(kāi)發(fā)方法。螺旋式開(kāi)發(fā)方法提高了人員的利用率，使得軟件開(kāi)發(fā)的局部階段相互重疊，在整體上形成多道流水線(xiàn)重疊并行。顯然這又縮短了開(kāi)發(fā)的總周期。

　　項目開(kāi)發(fā)各階段的質(zhì)量保證

　　需求分析

　　需求分析是開(kāi)發(fā)人員對系統需要做什么和如何做的定義過(guò)程。從系統分析的經(jīng)驗來(lái)看，這個(gè)過(guò)程往往是個(gè)循序漸進(jìn)的過(guò)程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶(hù)領(lǐng)域專(zhuān)家進(jìn)行交流確認，方能逐步明了用戶(hù)的需求。從系統開(kāi)發(fā)的過(guò)程得知，系統分析時(shí)犯下的錯誤，會(huì )在接下來(lái)的階段被成倍的放大，越是在開(kāi)發(fā)的后期，糾正分析時(shí)犯下的錯誤所花費的代價(jià)越是昂貴，也越發(fā)影響系統的工期和系統的質(zhì)量。同時(shí)，想在某個(gè)時(shí)間點(diǎn)上宣布需求分析已經(jīng)完畢，不再需要進(jìn)行進(jìn)一步的需求分析，這也是不現實(shí)的。經(jīng)驗告訴我們，往往在測試過(guò)程中會(huì )發(fā)現，用戶(hù)真正想要的并非您腦海中的設想，另一方面用戶(hù)往往知道自己肯定不需要什么，而無(wú)法明確告知他們需要的是什么。面對這些事實(shí)，我們無(wú)法期望改變用戶(hù)；比如提高用戶(hù)同分析人員的“溝通”能力，讓他們說(shuō)出的話(huà)更能被分析人員理解。唯一的做法是采用一定的方式方法，誘導用戶(hù)盡可能早地將需求表達出來(lái)，表達得完整。

　　在某個(gè)項目中我們的做法有兩個(gè)方面：一是請領(lǐng)域專(zhuān)家參與到系統開(kāi)發(fā)的早期階段；二是開(kāi)發(fā)系統原形，原形包括功能性的原形和用戶(hù)界面性的原形，也可以是二者混合的原形，用這些原形確認用戶(hù)的需求。讓領(lǐng)域專(zhuān)家參與開(kāi)發(fā)的早期階段，是保證分析人員有充足的時(shí)間和領(lǐng)域專(zhuān)家進(jìn)行充分的交流和確認。在這個(gè)階段，原形可能在提交到用戶(hù)之前，首先被領(lǐng)域專(zhuān)家確認，這樣保證了原形被認可的程度和認可過(guò)程耗費的時(shí)間盡可能的短，從而在提高效率的同時(shí)保證了質(zhì)量。

　　在開(kāi)發(fā)方內部還有三項保證措施：系統分析委員會(huì )保證系統分析集思廣益；質(zhì)量監督組對分析工作的監督；技術(shù)支持人員參與需求調研。

　　分析委員會(huì )的意義在于任何分析人員在提交其所分析部分的分析說(shuō)明書(shū)前，必須通過(guò)委員會(huì )的共同審議，委員會(huì )的成員根據各自的分析經(jīng)驗和自身所分析的部分對他人的分析報告提出質(zhì)疑。如此審議過(guò)后保證了各部分間相互關(guān)聯(lián)的部分被明確定義，避免了由于“疏忽”造成系統在后期進(jìn)行整合時(shí)出現較嚴重的系統鴻溝或系統重疊。

　　質(zhì)量監督組在項目的任何階段都要提出監督計劃。按照監督計劃分配相應的資源來(lái)保證某階段的開(kāi)發(fā)質(zhì)量。分析階段的監督計劃會(huì )在分析任務(wù)之前被項目經(jīng)理，項目負責人、系統分析員以及技術(shù)支持所了解。為保證分析工作高質(zhì)量進(jìn)行，同時(shí)分析工作又不被過(guò)分打擾，質(zhì)量監督組則主要針對《系統分析報告》進(jìn)行復審，只在認為確實(shí)有必要的情況下才召開(kāi)質(zhì)量復審會(huì )議。質(zhì)量復審會(huì )議的主要參與者是項目經(jīng)理、項目負責人、分析人員和質(zhì)量監督組組長(cháng)。會(huì )議的主要議題是提出質(zhì)量質(zhì)疑，給出改進(jìn)建議即可。具體是否存在質(zhì)量問(wèn)題，是否需要改進(jìn)，不在會(huì )議中進(jìn)行討論。以此保證了會(huì )議參與的人數較少，會(huì )議的時(shí)間盡可能的短。

　　通過(guò)技術(shù)支持的職責可以發(fā)現，技術(shù)支持參與分析調研有利于對分析工作的監督，在獲得用戶(hù)需求的口頭表達之后，能幫助技術(shù)支持更好地扮演開(kāi)發(fā)階段“用戶(hù)”的角色。技術(shù)支持具有相當的計算機技術(shù)背景，在接下來(lái)的開(kāi)發(fā)過(guò)程中就能較好的起到監督的作用，也為將來(lái)維護和為用戶(hù)提供更好的服務(wù)奠定基礎。

　　系統設計

　　優(yōu)良的體系結構應當具備可擴展性和可配置性，這兩方面因素的實(shí)現是通過(guò)WindowsDNA的應用完成的，正如建議書(shū)中所述，在此不再贅述。

　　實(shí)現

　　實(shí)現也就是代碼的生產(chǎn)過(guò)程。從設計的結構圖中可以看出，生產(chǎn)的類(lèi)別有類(lèi)的生產(chǎn)，組件的生產(chǎn)，構件的生產(chǎn)，應用系統的整合，以及各種測試用例的生產(chǎn)。