減低開發(fā)過程變動(dòng) 依賴項(xiàng)目范圍管理

申請免費(fèi)試用、咨詢電話：400-8352-114

在上世紀(jì)70 年代后期，系統(tǒng)分析師、系統(tǒng)設(shè)計(jì)師，和其他從事軟件工程的專業(yè)人員一直爭取希望能夠有一個(gè)國際公認(rèn)的資格，類似會(huì)計(jì)師、律師、建筑師等專業(yè)的地位，但到了80 年代中期，這個(gè)議題已經(jīng)不再存在，主要的原因是軟件工程內(nèi)包含太多專業(yè)，除了軟件和硬件兩大類之外，還漸漸包括網(wǎng)絡(luò)，通信，數(shù)據(jù)庫等多方面。計(jì)算機(jī)從業(yè)人員開始體會(huì)及認(rèn)識(shí)到本身的工作與會(huì)計(jì)師、律師、建筑師等專業(yè)資格可以在考核及認(rèn)證后授予一定的權(quán)責(zé)，和建立一套環(huán)球衡量標(biāo)準(zhǔn)的模式是不一樣的。其實(shí)軟件工程比較像藝術(shù)家，大部份的軟件是模仿別人的成果加以個(gè)別的應(yīng)用需求進(jìn)行個(gè)性化的結(jié)果，把思維轉(zhuǎn)變成交付成果的一門專業(yè)。

過去數(shù)年常聽到一些軟件從業(yè)人員的投訴包括：“他們(客戶)基本上不知道自己的需求，怎么做他們都不滿意，功能不斷增加，如何能夠完成他們的系統(tǒng)建設(shè)?”“他們(客戶)上周說要這個(gè)功能，今天說要這個(gè)功能，為什么不全告訴我們，讓我們可以不用在開發(fā)過程中不斷更改!”一些類似的投訴只說明我們的軟件從業(yè)人員基本上沒有明白到范圍建設(shè)的重要性，而且未能在項(xiàng)目啟動(dòng)前把項(xiàng)目范圍建立起來。

范圍與功能的分別

在“如何把握不存在的需求”一文中，已經(jīng)說明范圍是有效管理需求變更的唯一方法。有明確的項(xiàng)目范圍，我們才能夠?qū)W習(xí)及分析范圍內(nèi)的作業(yè)流程，建立系統(tǒng)的功能需求，并在開發(fā)過程中當(dāng)客戶要求變動(dòng)的時(shí)候有效管理我們的工作范圍，才能夠有機(jī)會(huì)按照預(yù)算在指定的時(shí)間內(nèi)完成項(xiàng)目的交付。

軟件開發(fā)項(xiàng)目從開始到今天，一直以來客戶都不能夠告訴我們需要哪些功能，他們只能告訴我們系統(tǒng)需要完成哪些目標(biāo)?；仡櫋叭绾伟盐詹淮嬖诘男枨蟆?一文中的第一個(gè)例子，20世紀(jì)70 年代的客戶需要把庫存管理進(jìn)行自動(dòng)化，收到的指示會(huì)像下例：“建立一套庫存管理系統(tǒng)取代目前的人工作業(yè)流程”。這一句指示是唯一任務(wù)說明。系統(tǒng)分析員在接受這個(gè)任務(wù)后第一個(gè)工作是建立項(xiàng)目的Term of Reference (ToR)。系統(tǒng)分析員會(huì)進(jìn)行初步調(diào)查，通過簡單的訪談，與庫存部門負(fù)責(zé)人明確理解他們工作的開始點(diǎn)和終結(jié)點(diǎn)，得出的結(jié)果可能像下例：“從貨品(包括原材料，半成品及制成品)進(jìn)入倉庫開始，到貨品因應(yīng)生產(chǎn)或銷售申領(lǐng)要求離開倉庫為止，其中包括貨品存入量的統(tǒng)計(jì)，存放位置記錄，總庫存量統(tǒng)計(jì)，申領(lǐng)數(shù)目，檢貨，提取貨品，準(zhǔn)備出倉，最后更新貨品存量統(tǒng)計(jì)等工作過程”。這是所謂的Term of Reference，也是我們今天所認(rèn)識(shí)的項(xiàng)目范圍。

在用戶及管理層認(rèn)同上述的ToR 后，這個(gè)項(xiàng)目的負(fù)責(zé)人便需要估計(jì)需要對多少人進(jìn)行訪談，需要多久時(shí)間進(jìn)行訪談，需要多少時(shí)間對訪談結(jié)果進(jìn)行分析，多少時(shí)間建立項(xiàng)目需求，編寫需求說明書，需要多久進(jìn)行系統(tǒng)設(shè)計(jì)，多少程序員及多少時(shí)間進(jìn)行程序編寫，如何進(jìn)行測試，編寫系統(tǒng)文檔，編寫用戶手冊，什么時(shí)候在倉庫安裝終端，如何連接主機(jī)，什么時(shí)候進(jìn)行用戶培訓(xùn)，如何讓系統(tǒng)取代目前的人工作業(yè)等等有關(guān)工作計(jì)劃及時(shí)間表。

在系統(tǒng)分析員完成訪談后，便需要依據(jù)訪談結(jié)果進(jìn)行分析，理解什么時(shí)候知道有貨品進(jìn)入倉庫，什么時(shí)候更新有關(guān)數(shù)據(jù)，如何更新，采用哪些表單，倉庫人員如何決定貨品應(yīng)該存放在哪里，如何記錄有關(guān)信息，如何知道需要檢貨，什么時(shí)候進(jìn)行數(shù)據(jù)更新，如何分別哪些貨品要去生產(chǎn)部門或者直接送到客戶指定地點(diǎn)等等信息。這些信息便成為系統(tǒng)在不同過程中所需的功能需求。

從上述的開發(fā)過程說明中可以體現(xiàn)功能需求并不是客戶或用戶提供，是系統(tǒng)分析員在理解目前的人工作業(yè)后分析出來的結(jié)果。

在系統(tǒng)移交到倉庫中運(yùn)行前，倉庫中的工作人員需要對系統(tǒng)的操作進(jìn)行學(xué)習(xí)及測試。要知道當(dāng)時(shí)倉庫的工作人員并不是針對系統(tǒng)的功能進(jìn)行測試，是對系統(tǒng)能否滿足他們的工作過程進(jìn)行測試?；谶@批工作人員對人于工作業(yè)的過程十分理解，如果系統(tǒng)未能提供一些他們操作過程中的日常工作，他們會(huì)要求技術(shù)人員對系統(tǒng)進(jìn)行修改。這個(gè)過程讓我們誤會(huì)用戶是對功能需求進(jìn)行測試，這個(gè)誤會(huì)一直到今天讓我們把系統(tǒng)開發(fā)的焦點(diǎn)錯(cuò)誤地放在功能上，而不是系統(tǒng)的最終交付上。而系統(tǒng)的最終交付是否能夠滿足ToR 的要求是當(dāng)時(shí)項(xiàng)目成敗的主要指標(biāo)。

系統(tǒng)集成的范圍及需求

20世紀(jì)70 年代的項(xiàng)目多以部門單獨(dú)運(yùn)營為主，自動(dòng)化的目的是提升部門本身的運(yùn)營效率進(jìn)行系統(tǒng)建設(shè)。到80 年代，企業(yè)高層開始體會(huì)企業(yè)中的數(shù)據(jù)分散在不同的部門或子公司的部門中。哪些數(shù)據(jù)是最新的?哪些是最準(zhǔn)確的?應(yīng)該采用哪個(gè)部門的數(shù)據(jù)做決定呢?如何整合這些數(shù)據(jù)，如何獲得即時(shí)的數(shù)據(jù)，如何利用當(dāng)時(shí)的區(qū)際網(wǎng)絡(luò)(AreaNetwork)，客戶/服務(wù)端(Client/Server)，遙程存取 (Remote‐Access)數(shù)據(jù)庫(Data Base)等科技來更有效提升企業(yè)的運(yùn)營效率呢?這些問題提供軟件開發(fā)項(xiàng)目進(jìn)行系統(tǒng)集成及數(shù)據(jù)分享的工作，最終的目的還是環(huán)繞原來自動(dòng)化提升企業(yè)(不單是 70 年代提升部門)的整體運(yùn)營效率為主要目標(biāo)。