軟體專案範圍管理

 在上世紀70 年代後期，系統分析師、系統設計師，和其他從事軟體工程的專業人員一直爭取希望能夠有一個國際公認的資格，類似會計師、律師、建築師等專業的地位，但到了 80 年代中期，這個議題已經不再存在，主要的原因是軟體工程內包含太多專業，除了軟體和硬體兩大類之外，還漸漸包括網路，通訊，資料庫等多方面。計算機從業人 員開始體會及認識到本身的工作與會計師、律師、建築師等專業資格可以在考核及認證後授予一定的權責，和建立一套環球衡量標準的模式是不一樣的。其實軟體工 程比較像藝術家，大部份的軟體是模仿別人的成果加以個別的應用需求進行個性化的結果，把思維轉變成交付成果的一門專業。

　　過去數年常聽到一些軟體從業人員的投訴包括：“他們(客戶)基本上不 知道自己的需求，怎麼做他們都不滿意，功能不斷增加，如何能夠完成他們的系統建設?”“他們(客戶)上週說要這個功能，今天說要這個功能，為什麼不全告訴 我們，讓我們可以不用在開發過程中不斷更改!”一些類似的投訴只說明我們的軟體從業人員基本上沒有明白到範圍建設的重要性，而且未能在專案啟動前把專案範 圍建立起來。

　　範圍與功能的分別

　　在“如何把握不存在的需求”一文中，已經說明範圍是有效管理需求變更 的唯一方法。有明確的專案範圍，我們才能夠學習及分析範圍內的作業流程，建立系統的功能需求，並在開發過程中當客戶要求變動的時候有效管理我們的工作範 圍，才能夠有機會按照預算在指定的時間內完成專案的交付。

　　軟體開發專案從開始到今天，一直以來客戶都不能夠告訴我們需要哪些功 能，他們只能告訴我們系統需要完成哪些目標。回顧“如何把握不存在的需求”一文中的第一個例子，20世紀70 年代的客戶需要把庫存管理進行自動化，收到的指示會像下例：“建立一套庫存管理系統取代目前的人工作業流程”。這一句指示是唯一任務說明。系統分析員在接 受這個任務後第一個工作是建立專案的Term of Reference (ToR)。系統分析員會進行初步調查，通過簡單的訪談，與庫存部門負責人明確理解他們工作的開始點和終結點，得出的結果可能像下例：“從貨品(包括原材 料，半成品及製成品)進入倉庫開始，到貨品因應生產或銷售申領要求離開倉庫為止，其中包括貨品存入量的統計，存放位置記錄，總庫存量統計，申領數目，檢 貨，提取貨品，準備出倉，最後更新貨品存量統計等工作過程”。這是所謂的Term of Reference，也是我們今天所認識的專案範圍。

　　在使用者及管理層認同上述的ToR 後，這個專案的負責人便需要估計需要對多少人進行訪談，需要多久時間進行訪談，需要多少時間對訪談結果進行分析，多少時間建立專案需求，編寫需求說明書， 需要多久進行系統設計，多少程式設計師及多少時間進行程式編寫，如何進行測試，編寫系統文件，編寫使用者手冊，什麼時候在倉庫安裝終端，如何連線主機，什麼時候 進行使用者培訓，如何讓系統取代目前的人工作業等等有關工作計劃及時間表。

　　在系統分析員完成訪談後，便需要依據訪談結果進行分析，理解什麼時候 知道有貨品進入倉庫，什麼時候更新有關資料，如何更新，採用哪些表單，倉庫人員如何決定貨品應該存放在哪裡，如何記錄有關資訊，如何知道需要檢貨，什麼時 候進行資料更新，如何分別哪些貨品要去生產部門或者直接送到客戶指定地點等等資訊。這些資訊便成為系統在不同過程中所需的功能需求。

　　從上述的開發過程說明中可以體現功能需求並不是客戶或使用者提供，是系統分析員在理解目前的人工作業後分析出來的結果。

　　在系統移交到倉庫中執行前，倉庫中的工作人員需要對系統的操作進行學 習及測試。要知道當時倉庫的工作人員並不是針對系統的功能進行測試，是對系統能否滿足他們的工作過程進行測試。基於這批工作人員對人於工作業的過程十分理 解，如果系統未能提供一些他們操作過程中的日常工作，他們會要求技術人員對系統進行修改。這個過程讓我們誤會使用者是對功能需求進行測試，這個誤會一直到今 天讓我們把系統開發的焦點錯誤地放在功能上，而不是系統的最終交付上。而系統的最終交付是否能夠滿足ToR 的要求是當時專案成敗的主要指標。