194.可行性研究

 

第2章  可行性研究

 

• 目的：用最小的代價在儘量短的時間內肯定問題是否可以解決。

• 任務：肯定問題是否值得去解決。

• 首先須要進一步分析和澄清問題定義。

      分析問題定義階段初步肯定的規模和目標，正確的加以確定，有錯誤及時改正，對目標系統有任何約束和限制，必須把它們清楚地列舉出來。   

 

 

問題定義的內容

•問題的背景

•開發系統的現狀

•開發的理由和條件

•開發系統的問題要求、整體要求

•問題的性質、類型範圍

•要實現的目標

•功能規模

•實現目標的方案

•開發的條件、環境要求

 

 

問題定義舉例

      項目：教材銷售系統

•                背景：人工銷售效率低，容易出錯

•                項目目標：創建一個高效率的、無差錯的微機教材銷售系統

•                項目範圍：硬件利用現有微機，軟件開發費用不超過5000元

•                初步設想：增長缺書統計與採購功能

•                可行性研究：建議進行一週，費用不超過500元

 

 

學生選課註冊系統的《目標和範圍說明書》

項目：學生註冊選課系統。

•                 問題：在學分制試行過程當中，學生選課進行人工註冊效率低，容易衝突，任課教師難以得到及時有效的課程選修學生名單。

•                 項目目標：創建一個基於教學管理計算機網絡的學生學期選課註冊系統。

•                 項目範圍：硬件主要利用現有計算機教學管理網絡，增配少許專用設備，軟件開發費用預期2800元。

•                 初步設想：爲學生提供填寫選課卡片和計算機網絡終端查詢對話兩種選課方式，教學管理科可以對選課衝突學生進行隨即查詢，肯定調整。系統主要輸出課程註冊數據庫、學生課程表、課程成績記載單。

•                 可行性研究：由分析員和教學管理科進行，主要對系統實施方案和學校學生選課管理規程進行研究。建議進行大約10天，費用不超過200元。

 

 

2.1  可行性研究的任務

肯定問題是否值得去解決的下一步。

 

•導出系統的邏輯模型。

  探索若干種可供選擇的主要解法(即系統實現方案)。從下述三方面研究每種解法的可行性：

(1) 技術可行性，使用現有的技術能實現這個系統嗎?

(2) 經濟可行性，這個系統的經濟效益能超過它的開發成本嗎?

(3) 操做可行性，系統的操做方式在這個用戶組織內行得通嗎?

 

    可行性研究最根本的任務是對之後的行動方針提出建議。

    若是問題沒有可行的解，分析員應該建議中止這項開發工程。

    若是問題值得解，分析員應該推薦一個較好的解決方案，而且爲工程制定一個初步的計劃。

    可行性研究須要的時間長短取決於工程的規模。通常說來，可行性研究的成本只是預期的工程總成本的5%～10%。

 

2.2  可行性研究過程

可行性研究過程有下述一些步驟。

1. 複查系統規模和目標

   確保分析員正在解決的問題確實是要求他解決的問題。

2. 研究目前正在使用的系統

    現有的系統是信息的重要來源。新的目標系統必須也能完成它的基本功能；

    另外一方面，現有的系統必然有某些缺點，新系統必須能解決舊系統中存在的問題。

3. 導出新系統的高層邏輯模型

（數據流圖和數據字典）。

4. 進一步定義問題

    分析員應該和用戶一塊兒再次複查問題定義、工程規模和目標，以數據流圖和數據字典做爲討論的基礎。

    可行性研究的前4個步驟實質上構成一個循環。

    定義問題，分析這個問題，導出一個試探性的解；

    在此基礎上再次定義問題，再一次分析這個問題，修改這個解；

    繼續這個循環過程，直到提出的邏輯模型徹底符合系統目標。

5. 導出和評價供選擇的解法

    分析員應該從他建議的系統邏輯模型出發，導出若干個較高層次的(較抽象的)物理解法供比較和選擇。

   爲每一個在技術、操做和經濟等方面均可行的系統制定實現進度表。

6. 推薦行動方針

    是否繼續進行這項開發工程。

7. 草擬開發計劃

    制定工程進度表

    估計對各種開發人員和各類資源的須要狀況，指明何時使用以及使用多長時間。

    估計系統生命週期每一個階段的成本。

    給出下一個階段(需求分析)的詳細進度表和成本估計。

8. 書寫文檔提交審查

    把上述可行性研究各個步驟的工做結果寫成清晰的文檔，請用戶、客戶組織的負責人及評審組審查，以決定是否繼續這項工程及是否接受分析員推薦的方案。

 

2.3  系統流程圖

    系統流程圖是歸納地描繪物理系統的傳統工具。它的基本思想是用圖形符號以黑盒子形式描繪組成系統的每一個部件(程序，文檔，數據庫，人工過程等)。

    系統流程圖表達的是數據在系統各部件之間流動的狀況，而不是對數據進行加工處理的控制過程，所以儘管系統流程圖的某些符號和程序流程圖的符號形式相同，可是它倒是物理數據流圖而不是程序流程圖。

 

2.3.1  符號

    當以歸納的方式抽象地描繪一個實際系統時，僅僅使用圖2.1中列出的基本符號就足夠了。

    當須要更具體地描繪一個物理系統時還須要使用圖2.2（見書29頁）中列出的系統符號。

    利用這些符號能夠把一個廣義的輸入輸出操做具體化爲讀寫存儲在特殊設備上的文件（或數據庫），把抽象處理具體化爲特定的程序或手工操做等。

 

 

圖2.1 基本符號

2.3.2  例子

    舉例說明系統流程圖的用法。

    某裝配廠有一座存放零件的倉庫，倉庫中現有的各類零件的數量以及每種零件的庫存量臨界值等數據記錄在庫存清單主文件中。

    當倉庫中零件數量有變化時，應該及時修改庫存清單主文件，

    若是哪一種零件的庫存量少於它的庫存量臨界值，則應該報告給採購部門以便訂貨，規定天天向採購部門送一次訂貨報告。

    該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產生訂貨報告的任務。零件庫存量的每一次變化稱爲一個事務，由放在倉庫中的CRT終端輸入到計算機中；系統中的庫存清單程序對事務進行處理，更新存儲在磁盤上的庫存清單主文件，而且把必要的訂貨信息寫在磁帶上。最後，天天由報告生成程序讀一次磁帶，而且打印出訂貨報告。圖2.3的系統流程圖描繪了上述系統的概貌。

    圖中每一個符號用黑盒子形式定義了組成系統的一個部件，然而並無指明每一個部件的具體工做過程；圖中的箭頭肯定了信息經過系統的邏輯路徑。

系統流程圖的習慣畫法是使信息在圖中從頂向下或從左向右流動。

 

圖2.3 庫存清單系統的系統流程圖

 

2.3.3  分層

    面對複雜的系統時，一個比較好的方法是分層次地描繪這個系統。

    首先用一張高層次的系統流程圖描繪系統整體概貌，代表系統的關鍵功能。

    而後分別把每一個關鍵功能擴展到適當的詳細程度，畫在單獨的一頁紙上。

    這種分層次的描繪方法便於閱讀者按從抽象到具體的過程逐步深刻地瞭解一個複雜的系統。

2.4  數據流圖

    數據流圖(DFD)是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程當中所經受的變換。在數據流圖中沒有任何具體的物理部件，它只是描繪數據在軟件中流動和被處理的邏輯過程。

    數據流圖是系統邏輯功能的圖形表示，即便不是專業的計算機技術人員也容易理解它，所以是分析員與用戶之間極好的通訊工具。

     此外，設計數據流圖時只需考慮系統必須完成的基本邏輯功能，徹底不須要考慮怎樣具體地實現這些功能，因此它也是從此進行軟件設計的很好的出發點。

2.4.1  符號

    如圖2.4(a)（見書31頁）所示，數據流圖有四種基本符號：正方形(或立方體)表示數據的源點或終點；圓角矩形(或圓形)表明變換數據的處理；開口矩形(或兩條平行橫線)表明數據存儲；箭頭表示數據流，即特定數據的流動方向。

    注意，數據流與程序流程圖(參看本書第5章)中用箭頭表示的控制流有本質不一樣，千萬不要混淆。

    在數據流圖中應該描繪全部可能的數據流向，而不該該描繪出現某個數據流的條件（沒法表示分支條件或循環）。

    處理並不必定是一個程序。一個處理框能夠表明一系列程序、單個程序或者程序的一個模塊；它甚至能夠表明用穿孔機穿孔或目視檢查數據正確性等人工處理過程。

    一個數據存儲也並不等同於一個文件，它能夠表示一個文件、文件的一部分、數據庫的元素或記錄的一部分等；數據能夠存儲在磁盤、磁帶、磁鼓、主存、微縮膠片、穿孔卡片及其餘任何介質上(包括人腦)。

    數據存儲和數據流都是數據，僅僅所處的狀態不一樣。數據存儲是處於靜止狀態的數據，數據流是處於運動中的數據。

    一般在數據流圖中忽略出錯處理，也不包括諸如打開或關閉文件之類的內務處理。

    數據流圖的基本要點是描繪「作什麼」而不考慮「怎樣作」。

    有時數據的源點和終點相同，若是隻用一個符號表明數據的源點和終點，則至少將有兩個箭頭和這個符號相連(一個進一個出)，可能其中一條箭頭線至關長，這將下降數據流圖的清晰度。另外一種表示方法是再重複畫一個一樣的符號(正方形或立方體)表示數據的終點。

    有時數據存儲也須要重複，以增長數據流圖的清晰程度。爲了不可能引發的誤解，若是表明同一個事物的一樣符號在圖中出如今n個地方，則在這個符號的一個角上畫（n-1）條短斜線作標記。

    除了上述4種基本符號以外，有時也使用幾種附加符號。圖2.4(b)給出了這些附加符號的含義。

2.4.2  例子

    假設一家工廠的採購部天天須要一張訂貨報表，報表按零件編號排序，表中列出全部須要再次訂貨的零件。

    對於須要再次訂貨的零件應該列出下述數據：

    零件編號，零件名稱，訂貨數量，目前價格，主要供應者，次要供應者。

    零件入庫或出庫稱爲事務，經過放在倉庫中的CRT終端把事務報告給訂貨系統。當某種零件的庫存數量少於庫存量臨界值時就應該再次訂貨。

 

數據流圖有4種成分：

    源點或終點，處理，數據存儲和數據流。

    所以，第一步能夠從問題描述中提取數據流圖的4種成分：

• 首先考慮數據的源點和終點

    從上面對系統的描述能夠知道「採購部天天須要一張訂貨報表」，「經過放在倉庫中的CRT終端把事務報告給訂貨系統」，因此採購員是數據終點，而倉庫管理員是數據源點。

•處理

    再一次閱讀問題描述，「採購部須要報表」，顯然他們尚未這種報表，所以必須有一個用於產生報表的處理。

    事務的後果是改變零件庫存量，然而任何改變數據的操做都是處理，所以對事務進行的加工是另外一個處理。

    注意，在問題描述中並無明顯地提到須要對事務進行處理，可是經過分析能夠看出這種須要。

•  數據流：

     系統把訂貨報表送給採購部，所以訂貨報表是一個數據流；事務須要從倉庫送到系統中，顯然事務是另外一個數據流。

• 數據存儲：

    產生報表和處理事務這兩個處理在時間上明顯不匹配——

    每當有一個事務發生時當即處理它，

    然而天天只產生一次訂貨報表。

    所以，用來產生訂貨報表的數據必須存放一段時間，也就是應該有一個數據存儲。

    注意，並非全部數據存儲和數據流都能直接從問題描述中提取出來。

 

    數據流圖是系統的邏輯模型，然而任何計算機系統實質上都是信息處理系統，也就是說計算機系統本質上都是把輸入數據變換成輸出數據。

    所以，任何系統的基本模型都由若干個數據源點/終點以及一個處理組成，這個處理就表明了系統對數據加工變換的基本功能。

    對於上述的訂貨系統能夠畫出圖2.5這樣的基本系統模型。

 

圖2.5 訂貨系統的基本系統模型

 

    從基本系統模型這樣很是高的層次開始畫數據流圖是一個好辦法。在這個高層次的數據流圖上是否列出了全部給定的數據源點/終點是一目瞭然的，所以它是頗有價值的通訊工具。

    然而，圖2.5畢竟太抽象了，從這張圖上對訂貨系統所能瞭解到的信息很是有限。

    下一步應該把基本系統模型細化，描繪系統的主要功能。

    從表2.1可知，「產生報表」和「處理事務」是系統必須完成的兩個主要功能，它們將代替圖2.5中的「訂貨系統」(圖2.6)。

 

    此外，細化後的數據流圖中還增長了兩個數據存儲：

    處理事務須要「庫存清單」數據；

    產生報表和處理事務在不一樣時間，所以須要存儲「訂貨信息」。

    除了表2.1中列出的兩個數據流以外還有另外兩個數據流，它們與數據存儲相同。

    這是由於從一個數據存儲中取出來的或放進去的數據一般和原來存儲的數據相同，也就是說，數據存儲和數據流只不過是一樣數據的兩種不一樣形式。

    在圖2.6中給處理和數據存儲都加了編號，這樣作的目的是便於引用和追蹤。

 

圖2.6 訂貨系統的功能級數據流圖

 

    接下來應該對功能級數據流圖中描繪的系統主要功能進一步細化。

    考慮經過系統的邏輯數據流：當發生一個事務時必須首先接收它；隨後按照事務的內容修改庫存清單；最後若是更新後的庫存量少於庫存量臨界值時，則應該再次訂貨，也就是須要處理訂貨信息。

    所以，把「處理事務」這個功能分解爲下述3個步驟，這在邏輯上是合理的：「接收事務」、「更新庫存清單」和「處理訂貨」(圖2.7)。

    當對數據流圖分層細化時必須保持信息連續性，也就是說，當把一個處理分解爲一系列處理時，分解前和分解後的輸入輸出數據流必須相同。

 

圖2.7 把處理事務的功能進一步分解後的數據流圖

 

 

2.4.3  命名

    數據流圖中每一個成分的命名是否恰當，直接影響數據流圖的可理解性。所以，給這些成分起名字時應該仔細推敲。下面講述在命名時應注意的問題：

1. 爲數據流(或數據存儲)命名

(1) 名字應表明整個數據流(或數據存儲)的內容，而不是僅僅反映它的某些成分。

(2) 不要使用空洞的、缺少具體含義的名字(如「數據」、「信息」、「輸入」之類)。

(3) 若是在爲某個數據流(或數據存儲)起名字時遇到了困難，則極可能是由於對數據流圖分解不恰當形成的，應該試試從新分解，看是否能克服這個困難。

2. 爲處理命名

(1) 一般先爲數據流命名，而後再爲與之相關聯的處理命名。這樣命名比較容易，並且體現了人類習慣的「由表及裏」的思考過程。

(2) 名字應該反映整個處理的功能，而不是它的一部分功能。

(3) 名字最好由一個具體的及物動詞加上一個具體的賓語組成。應該儘可能避免使用「加工」、「處理」等空洞籠統的動詞做名字。

(4) 一般名字中僅包括一個動詞，若是必須用兩個動詞才能描述整個處理的功能，則把這個處理再分解成兩個處理可能更恰當些。

(5) 若是在爲某個處理命名時遇到困難，則極可能是發現了分解不當的跡象，應考慮從新分解。

數據源點/終點並不須要在開發目標系統的過程當中設計和實現，它並不屬於數據流圖的核心內容，只不過是目標系統的外圍環境部分(多是人員、計算機外部設備或傳感器裝置)。一般，爲數據源點/終點命名時採用它們在問題域中習慣使用的名字(如「採購員」、「倉庫管理員」等)。

2.4.4  用途

    畫數據流圖的基本目的是利用它做爲交流信息的工具。分析員把他對現有系統的認識或對目標系統的設想用數據流圖描繪出來，供有關人員審查確認。因爲在數據流圖中一般僅僅使用4種基本符號，並且不包含任何有關物理實現的細節，所以，絕大多數用戶均可以理解和評價它。

    數據流圖應該分層，而且在把功能級數據流圖細化後獲得的處理超過9個時，應該採用畫分圖的辦法，也就是把每一個主要功能都細化爲一張數據流分圖，而原有的功能級數據流圖用來描繪系統的總體邏輯概貌。

 

    數據流圖的另外一個主要用途是做爲分析和設計的工具。

    分析員在研究現有的系統時經常使用系統流程圖表達他對這個系統的認識，這種描繪方法形象具體，比較容易驗證它的正確性；

    可是，開發工程的目標每每不是徹底複製現有的系統，而是創造一個可以完成相同的或相似的功能的新系統。

    用系統流程圖描繪一個系統時，系統的功能和實現每一個功能的具體方案是混在一塊兒的。

    所以，分析員但願以另外一種方式進一步總結現有的系統，這種方式應該着重描繪系統所完成的功能而不是系統的物理實現方案。數據流圖是實現這個目標的極好手段。

 

    當用數據流圖輔助物理系統的設計時，以圖中不一樣處理的定時要求爲指南，可以在數據流圖上畫出許多組自動化邊界，每組自動化邊界可能意味着一個不一樣的物理系統，所以能夠根據系統的邏輯模型考慮系統的物理實現。

    例如，考慮圖2.7，事務隨時可能發生，所以處理1.1(「接收事務」)必須是聯機的；採購員天天須要一次訂貨報表，所以處理2(「產生報表」)應該以批量方式進行。

    問題描述並無對其餘處理施加限制，例如，能夠聯機地接收事務並放入隊列中，然而更新庫存清單、處理訂貨和產生報表以批量方式進行(圖2.8)。固然，這種方案須要增長一個數據存儲以存放事務數據。

 

圖2.8 這種劃分自動化邊界的方法暗示以批量方式更新庫存清單

 

    改變自動化邊界，把處理1.1，1.2和1.3放在同一個邊界內(圖2.9)，這個系統將聯機地接收事務、更新庫存清單和處理訂貨及輸出訂貨信息；然而處理2將以批量方式產生訂貨報表。

    還能設想出創建自動化邊界的其餘方案嗎?

    若是把處理1.1和處理1.2放在一個自動化邊界內，把處理1.3和處理2放在另外一個邊界內，意味着什麼樣的物理系統呢?

    數據流圖對更詳細的設計步驟也有幫助，本書第5章將講述從數據流圖出發映射出軟件結構的方法——面向數據流的設計方法。

 

 

 

 

圖2.9 另外一種劃分自動化邊界的方法建議以聯機方式更新庫存清單

 

2.5  數據字典

    數據字典是關於數據的信息的集合，也就是對數據流圖中包含的全部元素的定義的集合。

    任何字典最主要的用途都是供人查閱對不瞭解的條目的解釋，數據字典的做用也正是在軟件分析和設計的過程當中給人提供關於數據的描述信息。

    數據流圖和數據字典共同構成系統的邏輯模型，沒有數據字典數據流圖就不嚴格，然而沒有數據流圖數據字典也難於發揮做用。只有數據流圖和對數據流圖中每一個元素的精肯定義放在一塊兒，才能共同構成系統的規格說明。

2.5.1  數據字典的內容

    通常說來，數據字典應該由對下列4類元素的定義組成：

(1) 數據流

(2) 數據流份量(即數據元素)

(3) 數據存儲

(4) 處理

    可是，對數據處理的定義用其餘工具(如IPO圖或PDL)描述更方便，所以本書中數據字典將主要由對數據的定義組成，這樣作可使數據字典的內容更單純，形式更統一。

    除了數據定義以外，數據字典中還應該包含關於數據的一些其餘信息。

    典型的狀況是，在數據字典中記錄數據元素的下列信息： 通常信息(名字，別名，描述等等)，定義(數據類型，長度，結構等等)，使用特色(值的範圍，使用頻率，使用方式——輸入、輸出、本地，條件值等等)，控制信息(來源，用戶，使用它的程序，改變權，使用權等等)和分組信息(父結構，從屬結構，物理位置——記錄、文件和數據庫等等)。

    數據元素的別名就是該元素的其餘等價的名字，出現別名主要有下述3個緣由：

(1) 對於一樣的數據，不一樣的用戶使用了不一樣的名字；

(2) 一個分析員在不一樣時期對同一個數據使用了不一樣的名字；

(3) 兩個分析員分別分析同一個數據流時，使用了不一樣的名字。

雖然應該儘可能減小出現別名，可是不可能徹底消除別名。

2.5.2  定義數據的方法

    定義絕大多數復瑣事物的方法，都是用被定義的事物的成分的某種組合表示這個事物，這些組成成分又由更低層的成分的組合來定義。從這個意義上說，定義就是自頂向下的分解，因此數據字典中的定義就是對數據自頂向下的分解。那麼，應該把數據分解到什麼程度呢?通常說來，當分解到不須要進一步定義，每一個和工程有關的人也都清楚其含義的元素時，這種分解過程就完成了。

    由數據元素組成數據的方式只有下述三種基本類型：

(1) 順序  即以肯定次序鏈接兩個或多個份量；

(2) 選擇  即從兩個或多個可能的元素中選取一個；

(3) 重複  即把指定的份量重複零次或屢次。

    所以，可使用上述3種關係算符定義數據字典中的任何條目。爲了說明重複次數，重複算符一般和重複次數的上下限同時使用(當上下限相同時表示重複次數固定)。當重複的上下限分別爲1和0時，能夠用重複算符表示某個份量是可選的。可是，「可選」是由數據元素組成數據時一種常見的方式，把它單獨列爲一種算符可使數據字典更清晰一些。所以，增長了下述的第4種關係算符：

(4) 可選  即一個份量是無關緊要的(重複零次或一次)。

    雖然可使用天然語言描述由數據元素組成數據的關係，可是爲了更加清晰簡潔，建議採用下列符號：

=意思是等價於(或定義爲)；

+意思是和(即，鏈接兩個份量)；

［ ］意思是或(即，從方括弧內列出的若干個份量中選擇一個)，一般用「|」號隔開供選擇的份量；

{  }意思是重複(即，重複花括弧內的份量)；

(  )意思是可選(即，圓括弧裏的份量無關緊要)。

 

    經常使用上限和下限進一步註釋表示重複的花括弧。一種註釋方法是在開括弧的左邊用上角標和下角標分別代表重複的上限和下限；另外一種註釋方法是在開括弧左側標明重複的下限，在閉括弧的右側標明重複的上限。

    下面舉例說明上述定義數據的符號的使用方法：某程序設計語言規定，用戶說明的標識符是長度不超過8個字符的字符串，其中第一個字符必須是字母字符，隨後的字符既能夠是字母字符也能夠是數字字符。使用上面講過的符號，咱們能夠像下面那樣定義標識符：

標識符=字母字符+字母數字串

字母數字串=0｛字母或數字｝7

字母或數字=［字母字符｜數字字符］

    因爲和項目有關的人都知道字母字符和數字字符的含義，所以，關於標識符的定義分解到這種程度就能夠結束了。

2.5.3  數據字典的用途

    數據字典最重要的用途是做爲分析階段的工具。 

    在數據字典中創建的一組嚴密一致的定義頗有助於改進分析員和用戶之間的通訊，所以將消除許多可能的誤解。

    對數據的這一系列嚴密一致的定義也有助於改進在不一樣的開發人員或不一樣的開發小組之間的通訊。

    若是要求全部開發人員都根據公共的數據字典描述數據和設計模塊，則能避免許多麻煩的接口問題。

    數據字典中包含的每一個數據元素的控制信息是頗有價值的。

    由於列出了使用一個給定的數據元素的全部程序(或模塊)，因此很容易估計改變一個數據將產生的影響，而且能對全部受影響的程序或模塊做出相應的改變。

    最後，數據字典是開發數據庫的第一步，並且是頗有價值的一步。

2.5.4  數據字典的實現

    目前，數據字典幾乎老是做爲CASE「結構化分析與設計工具」的一部分實現的。

    在開發大型軟件系統的過程當中，數據字典的規模和複雜程度迅速增長，人工維護數據字典幾乎是不可能的。

    若是在開發小型軟件系統時暫時沒有數據字典處理程序，建議採用卡片形式書寫數據字典，每張卡片上保存描述一個數據的信息。這樣作更新和修改起來比較方便，並且能單獨處理描述每一個數據的信息。每張卡片上主要應該包含下述這樣一些信息：

名字、別名、描述、定義、位置。

2.6  成本/效益分析

    開發一個軟件系統是一種投資，指望未來得到更大的經濟效益。

    經濟效益一般表現爲減小運行費用或(和)增長收入。可是，投資開發新系統每每要冒必定風險，系統的開發成本可能比預計的高，效益可能比預期的低。

    效益分析的目的正是要從經濟角度分析開發一個特定的新系統是否划算，從而幫助客戶組織的負責人正確地做出是否投資於這項開發工程的決定。

    爲了對比成本和效益，首先須要估計它們的數量。

2.6.1  成本估計

    軟件開發成本主要表現爲人力消耗(乘以平均工資則獲得開發費用)。成本估計不是精確的科學，所以應該使用幾種不一樣的估計技術以便相互校驗。下面簡單介紹3種估算技術。

1. 代碼行技術

    代碼行技術是比較簡單的定量估算方法，它把開發每一個軟件功能的成本和實現這個功能須要用的源代碼行數聯繫起來。一般根據經驗和歷史數據估計實現一個功能須要的源程序行數。當有以往開發相似工程的歷史數據可供參考時，這個方法是很是有效的。

    一旦估計出源代碼行數之後，用每行代碼的平均成本乘以行數就能夠肯定軟件的成本。每行代碼的平均成本主要取決於軟件的複雜程度和工資水平。

2. 任務分解技術

    這種方法首先把軟件開發工程分解爲若干個相對獨立的任務。再分別估計每一個單獨的開發任務的成本，最後累加起來得出軟件開發工程的總成本。

    估計每一個任務的成本時，一般先估計完成該項任務須要用的人力(以人月爲單位)，再乘以每人每個月的平均工資而得出每一個任務的成本。

    最經常使用的辦法是按開發階段劃分任務。若是軟件系統很複雜，由若干個子系統組成，則能夠把每一個子系統再按開發階段進一步劃分紅更小的任務。

    典型環境下各個開發階段須要使用的人力的百分比大體如表2.2（見書40頁）所示。固然，應該針對每一個開發工程的具體特色，而且參照以往的經驗儘量準確地估計每一個階段實際須要使用的人力。

3. 自動估計成本技術

    採用自動估計成本的軟件工具能夠減輕人的勞動，而且使得估計的結果更客觀。可是，採用這種技術必須有長期蒐集的大量歷史數據爲基礎，而且須要有良好的數據庫系統支持。

2.6.2  成本/效益分析的方法

    成本/效益分析的第一步是估計開發成本、運行費用和新系統將帶來的經濟效益。

• 估計開發成本以介紹。

• 運行費用取決於系統的操做費用(操做員人數，工做時間，消耗的物資等等)和維護費用。

• 系統的經濟效益等於因使用新系統而增長的收入加上使用新系統能夠節省的運行費用。

    由於運行費用和經濟效益二者在軟件的整個生命週期內都存在，總的效益和生命週期的長度有關，因此應該合理地估計軟件的壽命。

    雖然許多系統在開發時預期生命週期長達10年以上，可是時間越長系統被廢棄的可能性也越大，爲了保險起見，之後在進行成本/效益分析時一概假設生命週期爲5年。

    應該比較新系統的開發成本和經濟效益，以便從經濟角度判斷這個系統是否值得投資，可是，投資是如今進行的，效益是未來得到的，不能簡單地比較成本和效益，應該考慮貨幣的時間價值。

1. 貨幣的時間價值

    一般用利率的形式表示貨幣的時間價值。

    假設年利率爲i，若是如今存入P元，則n年後能夠獲得的錢數爲：F=P(1+i)ⁿ

    這也就是P元錢在n年後的價值。

    反之，若是n年後能收入F元錢，那麼這些錢的如今價值是

    P=F/(1+i)ⁿ

    例如，修改一個已有的庫存清單系統，使它能在天天送給採購員一份訂貨報表。

    修改已有的庫存清單程序而且編寫產生報表的程序，估計共需5000元；

    系統修改後能及時訂貨將消除零件短缺問題，估計所以每一年能夠節省2500元，5年共可節省12500元。

    可是，不能簡單地把5000元和12500元相比較，由於前者是如今投資的錢，後者是若干年之後節省的錢。

    假定年利率爲12%，利用上面計算貨幣如今價值的公式能夠算出修改庫存清單系統後每一年預計節省的錢的如今價值，如表2.3（見書41頁）所示。

 

2. 投資回收期

    一般用投資回收期衡量一項開發工程的價值。

    所謂投資回收期就是使累計的經濟效益等於最初投資所須要的時間。

    顯然，投資回收期越短就能越快得到利潤，所以這項工程也就越值得投資。

    舉例：參見P42

    投資回收期僅僅是一項經濟指標，爲了衡量一項開發工程的價值，還應該考慮其餘經濟指標。

 

3. 純收入

    衡量工程價值的另外一項經濟指標是工程的純收入，也就是在整個生命週期以內系統的累計經濟效益(摺合成如今值)與投資之差。

    這至關於比較投資開發一個軟件系統和把錢存在銀行中(或貸給其餘企業)這兩種方案的優劣。

    若是純收入爲零，則工程的預期效益和在銀行存款同樣，可是開發一個系統要冒風險，所以從經濟觀點看這項工程多是不值得投資的。

    若是純收入小於零，那麼這項工程顯然不值得投資。

 

4. 投資回收率

    把資金存入銀行或貸給其餘企業可以得到利息，一般用年利率衡量利息多少。

    相似地也能夠計算投資回收率，用它衡量投資效益的大小，而且能夠把它和年利率相比較。

    在衡量工程的經濟效益時，它是最重要的參考數據。

    已知如今的投資額，而且已經估計出未來每一年能夠得到的經濟效益，那麼，給定軟件的使用壽命以後，怎樣計算投資回收率呢?

    設想把數量等於投資額的資金存入銀行，每一年年末從銀行取回的錢等於系統每一年預期能夠得到的效益，在時間等於系統壽命時，正好把在銀行中的存款所有取光，那麼，年利率等於多少呢?

    這個假想的年利率就等於投資回收率。

   

2.7  小結

    可行性研究進一步探討問題定義階段所肯定的問題是否有可行的解。

    在對問題正肯定義的基礎上，經過分析問題，導出試探性的解，而後複查並修正問題定義，再次分析問題，改進提出的解法……。

    通過定義問題、分析問題、提出解法的反覆過程，最終提出一個符合系統目標的高層次的邏輯模型。

    而後根據系統的這個邏輯模型設想各類可能的物理系統，而且從技術、經濟和操做等各方面分析這些物理系統的可行性。

    最後，系統分析員提出一個推薦的行動方針，提交用戶和客戶組織負責人審查批准。

 

    在表達分析員對現有系統的認識和描繪他對將來的物理系統的設想時，系統流程圖是一個很好的工具。系統流程圖實質上是物理數據流圖，它描繪組成系統的主要物理元素以及信息在這些元素間流動和處理的狀況。

    數據流圖的基本符號只有4種，它是描繪系統邏輯模型的極好工具。一般數據字典和數據流圖共同構成系統的邏輯模型。沒有數據字典精肯定義數據流圖中每一個元素，數據流圖就不夠嚴密；然而沒有數據流圖，數據字典也很難發揮做用。

    成本/效益分析是可行性研究的一項重要內容，是客戶組織負責人從經濟角度判斷是否繼續投資於這項工程的主要依據。