在用戶及管理層認同上述的ToR 后，這個項目的負責(zé)人便需要估計需要對多少人進行訪談，需要多久時間進行訪談，需要多少時間對訪談結(jié)果進行分析，多少時間建立項目需求，編寫需求說明書，需要多久進行系統(tǒng)設(shè)計，多少程序員及多少時間進行程序編寫，如何進行測試，編寫系統(tǒng)文檔，編寫用戶手冊，什么時候在倉庫安裝終端，如何連接主機，什么時候進行用戶培訓(xùn)，如何讓系統(tǒng)取代目前的人工作業(yè)等等有關(guān)工作計劃及時間表。
在系統(tǒng)分析員完成訪談后，便需要依據(jù)訪談結(jié)果進行分析，理解什么時候知道有貨品進入倉庫，什么時候更新有關(guān)數(shù)據(jù)，如何更新，采用哪些表單，倉庫人員如何決定貨品應(yīng)該存放在哪里，如何記錄有關(guān)信息，如何知道需要檢貨，什么時候進行數(shù)據(jù)更新，如何分別哪些貨品要去生產(chǎn)部門或者直接送到客戶指定地點等等信息。這些信息便成為系統(tǒng)在不同過程中所需的功能需求。
從上述的開發(fā)過程說明中可以體現(xiàn)功能需求并不是客戶或用戶提供，是系統(tǒng)分析員在理解目前的人工作業(yè)后分析出來的結(jié)果。
在系統(tǒng)移交到倉庫中運行前，倉庫中的工作人員需要對系統(tǒng)的操作進行學(xué)習(xí)及測試。要知道當(dāng)時倉庫的工作人員并不是針對系統(tǒng)的功能進行測試，是對系統(tǒng)能否滿足他們的工作過程進行測試�；谶@批工作人員對人于工作業(yè)的過程十分理解，如果系統(tǒng)未能提供一些他們操作過程中的日常工作，他們會要求技術(shù)人員對系統(tǒng)進行修改。這個過程讓我們誤會用戶是對功能需求進行測試，這個誤會一直到今天讓我們把系統(tǒng)開發(fā)的焦點錯誤地放在功能上，而不是系統(tǒng)的最終交付上。而系統(tǒng)的最終交付是否能夠滿足ToR 的要求是當(dāng)時項目成敗的主要指標。
系統(tǒng)集成的范圍及需求
20世紀70 年代的項目多以部門單獨運營為主，自動化的目的是提升部門本身的運營效率進行系統(tǒng)建設(shè)。到80 年代，企業(yè)高層開始體會企業(yè)中的數(shù)據(jù)分散在不同的部門或子公司的部門中。哪些數(shù)據(jù)是最新的?哪些是最準確的?應(yīng)該采用哪個部門的數(shù)據(jù)做決定呢?如何整合這些數(shù)據(jù)，如何獲得即時的數(shù)據(jù)，如何利用當(dāng)時的區(qū)際網(wǎng)絡(luò)(AreaNetwork)，客戶/服務(wù)端(Client/Server)，遙程存取(Remote‐Access)數(shù)據(jù)庫(Data Base)等科技來更有效提升企業(yè)的運營效率呢?這些問題提供軟件開發(fā)項目進行系統(tǒng)集成及數(shù)據(jù)分享的工作，最終的目的還是環(huán)繞原來自動化提升企業(yè)(不單是70 年代提升部門)的整體運營效率為主要目標。
這個時候，簡單的ToR 已經(jīng)不能夠說明項目的范圍，但可以采用多個ToR 來加以說明。工作說明(Statement of Work)在這個時候誕生，開始取代ToR 成為項目范圍的主要工具。一個項目可能有多個Statement of Work(SOW)才能夠有效說明項目包含的范圍。例如要建立一個 “訂單管理系統(tǒng)(Order Processing System)”的時候，這個系統(tǒng)可能包括銷售部門，庫存管理部門，會計部門，運輸部門，生產(chǎn)部門等，這些部門也可能分布在不同的地區(qū)。
此文章共有6頁 上一頁 1 2 3 4 5 6 下一頁
文章來源：希賽網(wǎng)
|
Leadge.com首頁 > 知識庫 