第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)n
這也就是P元錢在n年後的價值。
反之，如果n年後能收入F元錢，那麼這些錢的現在價值是
P=F/(1+i)n
例如，修改一個已有的庫存清單系統，使它能在每天送給採購員一份定貨報表。
修改已有的庫存清單程式並且編寫產生報表的程式，估計共需5000元；
系統修改後能及時定貨將消除零件短缺問題，估計因此每年可以節省2500元，5年共可節省12500元。
但是，不能簡單地把5000元和12500元相比較，因為前者是現在投資的錢，後者是若干年以後節省的錢。
假定年利率為12%，利用上面計算貨幣現在價值的公式可以算出修改庫存清單系統後每年預計節省的錢的現在價值，如表2.3（見書41頁）所示。
2. 投資回收期
通常用投資回收期衡量一項開發工程的價值。
所謂投資回收期就是使累計的經濟效益等於最初投資所需要的時間。
顯然，投資回收期越短就能越快獲得利潤，因此這項工程也就越值得投資。
舉例：參見P42
投資回收期僅僅是一項經濟指標，為了衡量一項開發工程的價值，還應該考慮其他經濟指標。
3. 純收入
衡量工程價值的另一項經濟指標是工程的純收入，也就是在整個生命週期之內系統的累計經濟效益(摺合成現在值)與投資之差。
這相當於比較投資開發一個軟體系統和把錢存在銀行中(或貸給其他企業)這兩種方案的優劣。
如果純收入為零，則工程的預期效益和在銀行存款一樣，但是開發一個系統要冒風險，因此從經濟觀點看這項工程可能是不值得投資的。
如果純收入小於零，那麼這項工程顯然不值得投資。
4. 投資回收率
把資金存入銀行或貸給其他企業能夠獲得利息，通常用年利率衡量利息多少。
類似地也可以計算投資回收率，用它衡量投資效益的大小，並且可以把它和年利率相比較。
在衡量工程的經濟效益時，它是最重要的參考資料。
已知現在的投資額，並且已經估計出將來每年可以獲得的經濟效益，那麼，給定軟體的使用壽命之後，怎樣計算投資回收率呢?
設想把數量等於投資額的資金存入銀行，每年年底從銀行取回的錢等於系統每年預期可以獲得的效益，在時間等於系統壽命時，正好把在銀行中的存款全部取光，那麼，年利率等於多少呢?
這個假想的年利率就等於投資回收率。
2.7 小結
可行性研究進一步探討問題定義階段所確定的問題是否有可行的解。
在對問題正確定義的基礎上，通過分析問題，匯出試探性的解，然後複查並修正問題定義，再次分析問題，改進提出的解法……。
經過定義問題、分析問題、提出解法的反覆過程，最終提出一個符合系統目標的高層次的邏輯模型。
然後根據系統的這個邏輯模型設想各種可能的物理系統，並且從技術、經濟和操作等各方面分析這些物理系統的可行性。
最後，系統分析員提出一個推薦的行動方針，提交使用者和客戶組織負責人審查批准。
在表達分析員對現有系統的認識和描繪他對未來的物理系統的設想時，系統流程圖是一個很好的工具。系統流程圖實質上是物理資料流圖，它描繪組成系統的主要物理元素以及資訊在這些元素間流動和處理的情況。
資料流圖的基本符號只有4種，它是描繪系統邏輯模型的極好工具。通常資料字典和資料流圖共同構成系統的邏輯模型。沒有資料字典精確定義資料流圖中每個元素，資料流圖就不夠嚴密；然而沒有資料流圖，資料字典也很難發揮作用。
成本/效益分析是可行性研究的一項重要內容，是客戶組織負責人從經濟角度判斷是否繼續投資於這項工程的主要依據。