軟體開發型資訊化專案監理初探（轉）

摘要：本文對軟體開發型資訊化專案的監理工作按照流程進行了設計：招標階段、總體規劃階段、需求分析階段、概要設計階段、詳細設計階段、編碼和測試階段、系統試執行階段；並介紹了每個階段監理方應承擔的工作。

　　關鍵詞：軟體開發型 專案監理 流程

　　Abstract: This paper designs the surveillance flows of information engineering that focused on software development: the phase of inviting public bidding、of laying out、of demand analysis、 of outline design、of detail design、of coding and testing 、of system test run , and presents the necessary work that the surveillant should do in the different phase.

　　Key words: project of software development surveillance flow

　　一、三種型別的資訊化監理專案介紹

　　按照資訊化工程專案本身的特點，資訊化工程專案監理可以劃分為三類：硬體網路整合專案的監理、軟體產品實施型資訊化專案的監理以及軟體開發型資訊化專案的監理。下面分別介紹這三類監理工作的特點：

　　硬體網路整合專案的監理：這類專案，主要包括綜合佈線和網路系統整合。這類監理最主要的特點是，硬體網路整合專案的評測標準是非常明確，易於執行的。比如，綜合佈線的監理依據有“中國工程建築標準化協會標準CESC89:97.5建築與建築群綜合佈線系統工程施工和驗收規範”、“中華人民共和國通訊行業標準YD/T926.11997大樓通訊綜合佈線系統”等，網路質量監理依據有“ANSIX3T9.5光纖分散式資料介面標準規範”等，這些都是直接面向結果的規範。所以，相對於軟體產品實施型資訊化專案的監理和軟體開發型資訊化專案的監理，硬體網路整合專案的監理是比較簡單的。

　　軟體產品實施型資訊化專案的監理：這類專案，主要是面向各廠商開發出來的產品軟體，選擇出合適的軟體產品，並根據企業需求進行實施。相對於硬體網路整合專案的監理，這類專案涉及到對於軟體應用的評測，而目前對於軟體評測，國家還沒有相應的標準來控制。事實上，軟體實施評測也不容易形成統一的標準，這造成了此類專案監理一定的難度。

　　軟體開發型資訊化專案的監理：這類專案，主要是基於一定的硬體網路設施，由承建方根據建設方需求開發出一套能夠滿足建設方需求的軟體系統。由於軟體開發工作，是知識密集程度非常高的工作，在某種程度上，也是非常個性化的。目前對於軟體開發專案的各種標準，多是針對軟體開發過程的控制，比如術語、文件等。因此這類專案監理也有一定難度。

　　筆者將結合自身的軟體開發型專案監理的經歷，就此類資訊化專案監理工作的流程研究進行初步的試探。

　　由於建設方和監理方的關係始於雙方監理合同的簽訂，所以本文的監理流程從監理合同簽訂開始。但鑑於在合同簽訂前監理方的前期準備工作是監理後續工作的基礎，因此先描述監理方的準備工作是非常必要的。

　　在簽訂監理合同之前，監理公司首先應對建設單位進行需求調研。此次需求調研的直接目的是為了編制更詳細的專案建議書以獲得監理合同，同時也是為招投標階段編制招標檔案做準備。此次調研主要明確如下問題：建設方在該專案上總體上要達到什麼目標？細分後分別是什麼目標？質量上要達到什麼要求？時間方面的要求？投資預算多少？等。最後完成專案建議書和初步監理規劃。

　　下面將詳細敘述每個階段的特點及監理方在該階段的工作。

　　二、軟體開發型專案監理基本流程

　　1、招投標階段

　　在招投標階段，監理方主要工作是根據前期調研工作，協助建設方編制招標檔案，協助建設方評標及保管合同及文件。其中招標檔案應包括：投標人須知、招標專案性質、技術要求、質量要求、工期要求、培訓要求、驗收要求、報價要求、投標人資質等級要求、投標保證金要求、投標檔案編制要求、評標標準、履約擔保函、合同主要條款等內容。而協助評標工作主要則從以下方面入手：

　　⑴、技術方面

　　對於技術方面的評比，一般有兩種方法：一是比較法，二是打分法。比較法一般是從標書的技術部分中選取一些關鍵技術進行橫向比較，誰的引數最接近標書要求，誰的技術評比的名次就越靠前。相對於比較法，打分法的精確性更高些。打分法也是從標書中選擇關鍵技術引數，按照預定好的權值計算分值進行打分，分數高者就在技術方面具有更大優勢。兩種方法各有長短。打分法一般適用於需要提取的關鍵技術種類比較多比較複雜且具有較大的成熟度、能較清晰劃分高下的情況，但在目前的評標工作中，一般都是採用比較法。

　　在技術方面，同時還應該考慮投標單位的技術背景等資訊。比如公司具有的CMM等級，是否有過類似專案的開發經驗以及過去專案的客戶反饋等。

　　⑵、價格方面

　　在價格方面，監理方應協助招標方對評標價進行評比。在核算時應注意如下因素：

　　①、總報價是否等於各分項報價之和。如果總報價不等於各分項報價之和，則以各分項報價之和為準，價差按誤差處理。

　　②、貨幣轉換。如果投標價所使用的貨幣不一樣，則需根據開標當日中國國家外匯管理局公佈的各種貨幣對美元匯率的賣出價，將非美元報價折算成美元報價後再進行比較。

　　③、報價缺項的處理。對照投標檔案的要求核對每一項報價，如果發現有缺項報價，按規定必須先發函澄清，如果屬實則將這一標中所報該項的平均報價補充投標商缺項報價計算評標價格，並且註明該項補遺的相關指標在招標檔案中的序號及理由。如果缺項的總金額超過開標價格的5%時，則可視為重大偏差。

　　④、超範圍投標專案的處理。投標商在投標檔案中超過投標檔案規定範圍投報的專案，原則上不能作為增減因素修改評標價格，也不可以發函澄清其報價。只有當超範圍投標專案在報價表中有單獨列名報價時，經批准可以從評標價格中扣除，並且在表下注明該項報價在投標檔案中的編號以及理由。

　　經過調整補充所得到的報價則稱為評標價，對評標價進行評比和排序即得到價格方面的評測結果。

　　⑶、其它方面

　　任何產品的生產，都著重對質量、成本和交貨期三方面的控制。對於軟體開發專案，除了技術因素和價格因素，交貨期也是一個重要的指標。所以投標書所報的交貨期也需重點考慮。與此同時，技術規範中所要求的有關服務費用，投標人的信譽，售後服務等因素也需要考慮到。

　　2、總體規劃階段

　　在招投標階段確定中標人，甲乙雙方簽訂合同之後，整個專案就形成了建設方、承建方和監理方的三方並存協作的一個團體，因此合理統一的規劃就是專案成功的基礎。總體規劃階段的主要任務，就是在承建方制定出專案規劃後，對其專案規劃審查，並根據承建方的專案規劃，修訂前期制定的監理專案規劃。

　　監理規劃的性質，是監理方對整個專案工作的初步設計，是具體的監理活動的基礎。監理規劃一般由監理方在該專案的總監理工程師制定。其基本內容應包括：

　　⑴、工程概況。包括工程名稱、建設地址，專案組成及規模，預計總投資額，預計專案工期，工程質量等級，設計、開發單位名稱，工程特點等。

　　⑵、監理範圍和目標。監理範圍一般包括在工程各階段的質量控制、進度控制和投資控制，以及其它委託服務。監理目標以三大控制為目標。

　　⑶、主要監理措施。

　　⑷、監理組織機構。

　　⑸、專案監理工作制度。如監理方內部的工作會議制度、監理日誌制度、監理週報和月報制度，監理方與另兩方的定期溝通制度等。

　　這個階段結束時，監理方應提交：監理規劃。

　　3、需求分析階段

　　需求分析是專案建設的基石，監理方在需求分析階段應以尊重承建方的專案管理和專案分析能力為前提，在具體的任務開展上不深入、不干擾承建方的自主權。同時，監理方要充分發揮好專案監督及溝通建設方和承建方之間的橋樑作用。

　　需求分析的工作方法，通常有三個階段。

　　第一階段：訪談階段。這一階段是和具體使用者方的領導層、業務層人員的訪談式溝通，目的是從宏觀瞭解使用者需求方向和趨勢，瞭解現有組織構架、業務流程、軟硬體環境及使用情況。實現手段通常是事先將調查問卷髮放到待調研部門，然後在約定時間圍繞問卷進行交流訪談。

　　第二階段：深入階段。這一階段的工作是建立在訪談階段工作完成，承建方已經瞭解了使用者的組織構架、業務流程、軟硬體環境及使用情況等基本現狀的基礎之上。承建方根據以往專案經驗以及業務專家的經驗，和建設方共同探討業務模型的合理性、準確性和發展方向等問題，得到相對先進的業務模型。

　　第三階段：確認階段。在完成上兩階段的工作之後，就需要對具體的流程細化，對資料進行確認了。根據前兩個階段的工作，承建方應草擬出一份需求分析報告，並提供原型演示系統，和建設方進行進一步的討論，最終確定一份需求分析報告。

　　需要指出的是，在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。

　　監理方在這三個階段的工作，按照內容可以分為兩部分：監督和溝通。監督工作包括對需求分析階段的各種文件的保管監督，對承建方的訪談活動的監督，對需求分析報告、原型演示系統的確認等；溝通工作則表現在當建設方和承建方由於知識背景不同而在訪談過程中溝通不順暢的時候，監理方應利用自身優勢使得雙方順利理解對方。

　　需求分析階段，監理方可參考的標準有：GB938588計算機軟體需求說明編寫指南。

　　這個階段監理方應提交：在需求分析進行前提交需求分析階段監理細則、監理日誌、在需求分析結束後提交需求分析階段總結報告。

　　4、概要設計階段

　　概要設計，即將軟體需求轉化為資料結構和軟體的系統結構，一般包括資料設計和系統結構設計。其中資料設計側重於資料結構的定義，系統結構設計定義軟體系統各主要成份之間的關係。

　　在承建方進行概要設計的過程中，監理方需要監督以下方面：

　　⑴、制定規範

　　在進入軟體開發階段之初，首先應為軟體開發組制定在設計時應該共同遵守的標準，以便協調組內各成員的工作。包括：

　　閱讀和理解軟體需求說明書，確認使用者要求能否實現，明確實現的條件，從而確定設計的目標，以及它們的優先順序；

　　根據目標確定最合適的設計方法；

　　規定設計文件的編制標準；

　　規定編碼的資訊形式，與硬體，作業系統的介面規約，命名規則。

　　⑵、軟體系統結構的總體設計

　　根據需求分析，基於功能層次結構建立系統，其中包括採用某種設計方法，將系統按功能劃分成模組的層次結構、確定每個模組的功能、建立與已確定的軟體需求的對應關係、確定模組間的呼叫關係、確定模組間的介面、評估模組劃分的質量。

　　⑶、處理方式設計

　　處理方式設計要確定為實現系統的功能需求所必需的演算法，評估演算法的效能；確定為滿足系統的效能需求所必需的演算法和模組間的控制方式；確定外部訊號的接收傳送形式。

　　⑷、資料結構設計

　　根據需求分析報告進行資料庫設計。資料庫設計包括確定軟體涉及的檔案系統的結構以及資料庫的模式、子模式，進行資料完整性和安全性的設計；確定輸入，輸出檔案的詳細的資料結構；結合演算法設計，確定演算法所必需的邏輯資料結構及其操作；確定對邏輯資料結構所必需的那些操作的程式模組(軟體包)；限制和確定各個資料設計決策的影響範圍；若需要與作業系統或排程程式介面所必須的控制表等資料時，確定其詳細的資料結構和使用規則；資料的保護性設計；資料的一致性設計；冗餘性設計等。

　　⑸、可靠性設計

　　可靠性設計也叫做質量設計。在執行過程中，為了適應環境的變化和使用者新的要求，需經常對軟體進行改造和修正。在軟體開發的一開始就要確定軟體可靠性和其它質量指標，考慮相應措施，以使得軟體易於修改和易於維護。

　　⑹、概要設計階段的文件

　　概要設計階段完成時應編寫以下文件：概要設計說明書、資料庫設計說明書、使用者手冊、制定初步的測試計劃。


　　針對上述工作，監理方應按如下標準評定承建方的概要設計：

　　⑴、可追溯性：確認該設計是否覆蓋了所有已確定的軟體需求，軟體每一成份是否可追溯到某一項需求；

　　⑵、介面：確認該軟體的內部介面與外部介面是否已經明確定義，模組是否滿足高內聚和低耦合的要求，模組作用範圍是否在其控制範圍之內；

　　⑶、風險：確認該設計在現有技術條件下和預算範圍內是否能按時實現；

　　⑷、實用性：確認該設計對於需求的解決方案是否實用；

　　⑸、技術清晰度：確認該設計是否以一種易於翻譯成程式碼的形式表達；

　　⑹、可維護性：確認該設計是否考慮了方便未來的維護；

　　⑺、質量：確認該設計是否表現出良好的質量特徵；

　　⑻、各種選擇方案：看是否考慮過其它方案，比較各種選擇方案的標準是什麼；

　　⑼、限制：評估對該軟體的限制是否現實，是否與需求一致；

　　⑽、其它具體問題：對於文件、可測試性、設計過程等進行評估。

　　這個階段監理方應提交：在概要設計進行前提交總體設計階段監理細則、監理週記、在概要設計完成後提交概要設計監理報告。

　　5、詳細設計階段

　　詳細設計階段的直接目標是編寫詳細設計說明書，為此，承建方應做如下工作：

　　⑴、確定每個模組的演算法，用工具表達演算法的過程，寫出模組的詳細過程性描述；

　　⑵、確定每一模組的資料結構；

　　⑶、確定模組介面細節。

　　監理方在這個階段主要是在進度上進行控制，主要手段是定期與承建方溝通，檢查文件。

　　這個階段監理方應提交：在詳細設計進行前提交詳細設計階段監理細則、監理週記、在詳細設計完成後提交詳細設計說明書的確認報告。

　　6、編碼及測試階段

　　編碼是將詳細設計階段的設計思想用某種計算機語言實現的過程。監理方應從結構化程式設計原則來進行編碼工作的監理：

　　⑴、使用語言中的順序、選擇、重複等有限的基本控制結構表示程式邏輯；

　　⑵、選用的控制結構只准許有一個入口和一個出口；

　　⑶、程式語句組成容易識別的塊，每塊只有一個入口和一個出口；

　　⑷、複雜結構應該用基本控制結構進行組合巢狀來實現；

　　⑸、語言中沒有的控制結構，可用一段等價的程式段模擬，但要求該程式段在整個系統中應前後一致；

　　通常測試是伴隨著編碼而同時進行的。廣義上軟體測試並非只在這個階段才有，而是貫穿軟體需求分析、概要設計、詳細設計等階段的。本處的測試，則指程式碼測試。在測試階段，監理方應依據測試原則對承建方的測試進行監督：

　　⑴、應儘早的和不斷的進行軟體測試；

　　⑵、測試用例應由測試輸入資料和對應的預期輸出結果這兩部分組成；

　　⑶、程式設計師應避免檢查自己的程式；

　　⑷、在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件；

　　⑸、充分注意測試中的群集現象，即一般測試後程式中殘存的錯誤數目與該程式中已發現的錯誤數目成正比；

　　⑹、嚴格執行測試計劃，排除測試的隨意性；

　　⑺、應當對每一個測試結果做全面檢查。

　　⑻、妥善儲存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。

　　在編碼及測試階段監理方可參考的標準有：GB938688計算機軟體測試檔案編制規範、GB/T1250490計算機軟體質量標準保證計劃規範、GB/T1250590計算機軟體配置管理計劃規範、GB/T1553295計算機軟體單元測試等。

　　7、系統試執行階段

　　由於資訊化軟體一般都是比較大型的軟體，因此在完成了系統測試後還需要經過一段時間的試執行。系統試執行實際是測試的延續，檢查系統的穩定性、適用性等。監理方在這個階段的主要工作有：

　　⑴、稽核竣工文件資料的完整性、可讀性及其與工程實際的一致性；

　　⑵、稽核作業系統、應用系統等軟體配置與設計方案的符合性；

　　⑶、檢測驗證系統功能效能與合同的符合性；

　　⑷、檢查人員培訓計劃落實情況；

　　⑸、出具驗收報告；

　　⑹、幫助使用者制定系統執行管理規章制度；

　　⑺、在保修期內定期或不定期對專案進行質量檢查、督促承建方按合同要求進行維護。

　　小結

　　從監理合同簽訂開始到最後系統試執行結束，監理方工作在職能上可以歸結為兩點：溝通與監督。溝通的目標是建設方與承建方資訊對等，溝通的手段是定期或不定期召開工作會議；監督的目標是在質量、進度和投資上進行控制，監督的手段是合同管理和文件管理。

　　參考文獻

　　1.葛乃康，羅四維資訊工程建設監理電子工業出版社2002年
　　2.張海藩軟體工程導論清華大學出版社1998年
　　3.黃學戰專案需求階段的監理角色和方法論中國計算機報2003年第三期

[@more@]