軟件工程導論—可行性研究

1. 可行性研究

1.1. 可行性研究的目的

可行性研究實質上是要進行一次簡化了的系統分析和設計的過程,也就是在較高層次上以較抽象的方式進行的系統分析和設計的過程。這個過程通常結合了初步的需求分析,不做需求分析,就無法對需求進行可行性分析。它所需要的時間長短取決於工程的規模。一般說來,可行性研究的成本只是預期的工程總成本的5%到10%。

因此,可行性研究的目的不是解決問題,而是確定問題是否能夠並且值得去解決。

並非任何問題都有簡單明顯的解決辦法,事實上,許多問題不可能在預定的系統規模或時間期限之內解決。如果問題沒有可行的解,那麼花費在這項工程上的任何時間、人力、軟硬件資源和經費,都是無謂的浪費。可行性研究的目的,就是用最小的代價在儘可能短的時間內確定問題是否能夠解決。

如果問題沒有可行的解,分析員應該建議停止這項開發工程,以避免時間、資源、人力和金錢的浪費;如果問題值得解,分析員應該推薦一個較好的解決方案,並且爲工程制定一個初步的計劃。

1.2. 可行性研究過程

  1. 首先需要進一步分析和澄清問題定義。
  2. 在澄清了問題定義之後,分析員應該導出系統的邏輯模型。
  3. 然後從系統邏輯模型出發,探索若干種可供選擇的主要解法(即系統實現方案)。對每種解法都應該仔細研究它的可行性,一般說來,至少應該從下述三方面研究每種解法的可行性:
    (1)技術可行性:工使用現有的技術能實現這個系統嗎?
    (2)經濟可行性:這個系統的經濟效益能超過它的開發成本嗎?
    (3)操作可行性:系統的操作方式在這個用戶組織內行得通嗎?
    必要時還應該從法律、社會效益等更廣泛的方面研究每種解法的可行性。

展開來說,典型的可行性研究過程有下述一些步驟

  1. 複查系統規模和目標
    分析員對問題定義階段書寫的關於規模種目標的報告書進一步複查確認,改正含糊或不確切的敘述,清晰地描述對目標系統的一切限制和約束
  2. 研究目前正在使用的系統
    現有的系統是信息的重要來源,新的目標系統必須也能完成它的基本功能;另一方面,現有的系統必然有某些缺點,新系統必須能解決舊系統中存在的問題。此外,運行使用舊系統所需要的費用是一個重要的經濟指標,如果新系統不能增加收入或減少使用費用,那麼從經濟角度看新系統就不如舊系統
  3. 導出新系統的高層邏輯模型
    優秀的設計過程通常總是從現有的物理系統出發,導出現有系統的邏輯模型,再參考現有系統的邏輯模型,設想目標系統的邏輯模型,最後根據目標系統的邏輯模型建造新的物理系統;
    通過上一步的工作,分析員能夠使用數據流圖,描繪數據在系統中流動和處理的情況,從而概括地表達出他對新系統的設想。爲了把新系統描繪得更清晰準確,還應該有一個初步的數據字典,定義系統中使用的數據中。
  4. 進一步定義問題
    新系統的邏輯模型實質上表達了分析員對新系統必須做什麼的看法。分析員應該和用戶一起再次複查問題定義、工程規模和目標,這次複查應該把數據流圖和數據字典作爲討論的基礎。可行性研究的前4個步驟實質上構成一 個循環。
    分析員定義問題,分析這個問題,導出一個試探性的解。在此基礎上再次定義問題,再一次分析這個問題,修改這個解。繼續這個循環過程中直到提出的邏輯模型完全符合系統目標。
  5. 導出和評價供選擇的解法
    分析員應該從他建議的系統邏輯模型出發,導出若干個較高層次的(較抽象的)物理解法,供比較和選擇。導出供選擇的解法的最簡單的途徑,是從技術角度出發考慮解決問題的不同方案。
    首先,根據技術可行性的考慮初步排除一些不現實的系統方案。
    其次,考慮操作方面的可行性。分析員應該根據使用部門處理事務的原則和習慣檢查技術上可行的那些方案。
    最後考慮經濟方面的可行性。分析員應該估計餘下的每個可能的系統的開發成本和運行費用,並且估計相對於現有的系統而言這個系統可以節省的開支或可以增加的收入。
  6. 推薦行動方針
    根據可行性研究結果應該做出的一個關鍵性決定是,是否繼續進行這項開發工程。如果分析員認爲值得繼續進行這項開發工程,那麼他應該選擇一種最好的解法,並且說明選擇這個解決方案的理由。
    通常使用部門的負責人主要根據經濟上是否划算決定是否投資於一項開發工程,因此分析員對於所推薦的系統必須進行比較仔細的成本/效益分析。
  7. 草擬開發計劃
    分析員應該爲所推薦的方案草擬一份開發計劃,除了制定工程進度表之外還應該估計對各類開發人員和各種資源的需要情況,應該指明什麼時候使用以及使用多長時間。此外還應該估計系統生命週期每個階段的成本,最後應給出下一個階段(需求分析)的詳細進度表和成本估計。
  8. 書寫文檔提交審查
    應該把上述可行性研究各個步驟的工作結果寫成清晰的文檔,請用戶、客戶組織的負責人及評審組審查,以決定是否繼續這項工程及是否接受分析員推薦的方案

2. 系統流程圖

2.1. 系統流程圖概述

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

系統流程圖表達的是數據在系統各部件之間流動的情況,而不是對數據進行加工處理的控制過程,因此儘管系統流程圖的某些符號和程序流程圖的符號形式相同,但是它卻是物理數據流圖而不是程序流程圖。

2.2. 系統流程圖的圖符

利用符號可以把一個廣義的輸入輸出操作具體化爲讀寫存儲在特殊設備上的文件(或數據庫),把抽象處理具體化爲特定的程序或手工操作等。

圖符 名稱 說明
在這裏插入圖片描述 處理 能改變數據值或數據位置的加工或部件,例如,程序、處理機、人工加工等都是處理
在這裏插入圖片描述 輸入輸出 表示輸入或輸出(或既輸入又輸出),是一個廣義的不指明具體設備的符號
在這裏插入圖片描述 連接 指出轉到圖的另一部分或從圖的另一部分轉來,通常在同一頁上
在這裏插入圖片描述 換頁連接 指出轉到另一頁圖上或由另一頁圖轉來
在這裏插入圖片描述 數據流 用來連接其他符號,指明數據流動方向
在這裏插入圖片描述 穿孔卡片 表示用穿孔卡片輸入或輸出,也可表示一個穿孔卡片文件
在這裏插入圖片描述 文檔 通常表示打印輸出,也可表示用打印終端輸入數據
在這裏插入圖片描述 磁帶 磁帶輸入輸出,或表示一個磁帶文件
在這裏插入圖片描述 聯機存儲 表示任何種類的聯機存儲,包括磁盤、磁鼓、軟盤和海量存儲器件等
在這裏插入圖片描述 磁盤 磁盤輸入輸出,也可表示存儲在磁盤上的文件或數據庫
在這裏插入圖片描述 磁鼓 磁鼓輸入輸出,也可表示存儲在磁鼓上的文件或數據庫
在這裏插入圖片描述 顯示 CRT終端或類似的顯示部件,可用於輸入或輸出,也可既輸入又輸出
在這裏插入圖片描述 人工輸入 人工輸入數據的脫機處理,例如填寫表格
在這裏插入圖片描述 人工操作 人工完成的處理,例如會計在工資支票上簽名
在這裏插入圖片描述 輔助操作 使用設備進行的脫機操作
在這裏插入圖片描述 通信鏈路 通過遠程通信線路或鏈路傳送數據

2.3. 系統流程圖的例子

以一個簡單的例子進行講解

某裝配廠有一座存放零件的倉庫,倉庫中現有的各種零件的數量以及每種零件的存量臨界值等數據,記錄在庫存清單主文件中。當倉庫中零件數量有變化時,應該及時修改庫存清單主文件,如果那種零件的庫存量少於它的庫存量臨界值,則應該報告給採購部門以便訂貨,規定每天向採購部門送一次訂貨報告。

該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產生訂貨報告的任務,流程如下:

  1. 零件庫存量的每一次變化稱爲一個事務,由放在倉庫中的CRT終端輸入到計算機中;
  2. 系統中的庫存清單程序對事務進行處理,更新存儲在磁盤上的庫存清單主文件,並且把必要的訂貨信息寫在磁帶上;
  3. 最後,每天由報告生成程序讀一次磁帶,並且打印出訂貨報告。如下圖所示。

在這裏插入圖片描述

2.4. 系統流程圖的分層

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

首先用一張高層次的系統流程圖描繪系統總體概貌,表明系統的關鍵功能。然後分別把每個關鍵功能擴展到適當的詳細程度,畫在單獨的一頁紙上。這種分層次的描繪方法便於閱讀者按從抽象到具體的過程逐步深入地瞭解一個複雜的系統。

3. 數據流圖 Data Flow Diagram,DFD

3.1. 數據流圖的概念

數據流圖(DFD)是一種圖形化的交流工具和分析設計工具,它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。

在數據流圖中沒有任何具體的物理部件,它只是描繪數據在軟件中流動和被處理的邏輯過程,是系統邏輯功能的圖形表示,即使不是專業的計算機技術人員也容易理解它,因此是分析員與用戶之間極好的通信工具。

此外,設計數據流圖時只需考慮系統必須完成的基本邏輯功能,完全不需要考慮怎樣具體地實現這些功能。

下面的頂級DFD高度概括了數據流圖的處理過程,數據從外部實體流入目標系統進行加工,然後又流出到外部實體。
在這裏插入圖片描述

3.2. 數據流圖的基本圖符

數據流圖有四種基本符號:

  1. 正方形(或立方體),表示數據的源點或終點;
  2. 圓角矩形(或圓形),代表數據的加工處理;
  3. 開口矩形(或兩條平行橫線),代表數據存儲;
  4. 箭頭表示數據流,即特定數據的流動方向。

如下圖所示:

圖符 含義
在這裏插入圖片描述 數據的源點或終點
在這裏插入圖片描述 數據的加工處理
在這裏插入圖片描述 數據存儲
在這裏插入圖片描述 數據流

除了4個基本符號以外,數據流圖還有一個附加符號,如下圖所示:

圖符 含義
在這裏插入圖片描述 數據A和B同時輸入才能變換成數據C
在這裏插入圖片描述 數據A變換成B和C
在這裏插入圖片描述 數據A或B,或A和B同時輸入變換成C
在這裏插入圖片描述 數據A變換成B或C,或B和C
在這裏插入圖片描述 只有數據A或只有數據B(但不能A、B同時)輸入時變換成C
在這裏插入圖片描述 數據A變換成B或C,但不能變換成B和C

3.3. 繪製數據流圖

3.3.1. 繪製數據流圖的步驟

概括地說:自外向內,自頂向下,逐層細化,完善求精。

  1. 首先確定系統的輸入和輸出,以反映系統與外界環境的接口;
  2. 頂層數據流圖將軟件系統描述爲一個加工,以反映最主要業務處理流程,它代表系統本身。但它並未明確表達數據加工的要求;
  3. 從輸入端開始,根據系統業務工作流程,畫出數據流流經的各加工框,以反映數據的實際處理過程,逐步畫到輸出端,得到第一層數據流圖。對圖中的加工分別加以編號;
  4. 細化每一個加工框。如果加工框內還有數據流,可將這個加工框再細分成幾個“子加工框”,並在各子加工框之間畫出數據流;
  5. 一次細化一個加工。

數據流圖的細化可以連續進行,直到每一個加工只執行一個簡單操作爲止。就是說,直到每一個加工執行一個可以用程序實現的功能爲止。

3.3.2. 成分的命名

數據流圖中每個成分的命名是否恰當,直接影響數據流圖的可理解性。在命名時應注意的問題:

  1. 爲數據流(或數據存儲)命名
    (1)名字應代表整個數據流(或數據存儲)的內容,而不是僅僅反映它的某些成分;
    (2)不要使用空洞的、缺乏具體含義的名字(如"數據"、“信息”、"輸入"之類);
    (3)如果在爲某個數據流(或數據存儲)起名字時遇到了困難,則很可能是因爲對數據流圖分解不恰當造成的,應該試試重新分解,看是否能克服這個困難。
  2. 爲處理命名
    (1)通常先爲數據流命名,然後再爲與之相關聯的處理命名。這樣命名比較容易,而且體現了人類習慣的"由表及裏"的思考過程。
    (2)名字應該反映整個處理的功能,而不是它的一部分功能;
    (3)名字最好由一個具體的及物動詞加上一個具體的賓語組成。應該儘量避免使用"加工"、"處理"等空洞籠統的動詞作名字;
    (4)通常名字中僅包括一個動詞,如果必須用兩個動詞才能描述整個處理的功能,則把這個處理再分解成兩個處理可能更恰當些。
    (5)如果在爲某個處理命名時遇到困難,則很可能是發現了分解不當的跡象,應考慮重新分解。
  3. 爲數據源點/終點命名
    數據源點/終點並不需要在開發目標系統的過程中設計和實現,它並不屬於數據流圖的核心內容,只不過是目標系統的外圍環境部分(可能是人員、計算機外部設備或傳感器裝置)。通常,爲數據源點/終點命名時採用它們在問題域中習慣使用的名字(如"採購員"、"倉庫管理員"等)。

3.4. 數據流圖的例子

假設一家工廠的採購部每天需要一張訂貨報表,報表按零件編號排序,表中列出所有需要再次訂貨的零件。

對於每個需要再次訂貨的零件應該列出下述數據:零件編號、零件名稱、訂貨數量、目前價格、主要供應者、次要供應者。

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

按步驟對題幹進行分析,提取數據流圖的四種成分:

  1. 首先考慮數據的源點和終點,從上面對系統的描述可以知道"採購部每天需要一張訂貨報表",“通過放在倉庫中的CRT終端把事務報告給訂貨系統”,所以採購員是數據終點,而倉庫管理員是數據源點
  2. 這其中必須有一個用於產生報表的處理。事務的後果是改變零件庫存量,然而任何改變數據的操作都是處理,因此對事務進行的加工是另一個處理。注意,在問題描述中並沒有明顯地提到需要對事務進行處理,但是通過分析可以看出這種需要。
  3. 系統把訂貨報表送給採購部,因此訂貨報表是一個數據流;事務需要從倉庫送到系統中,顯然事務是另一個數據流。產生報表和處理事務這兩個處理在時間上明顯不匹配一每當有一個事務發生時立即處理它,然而每天只產生一次訂貨報表。因此,用來產生訂貨報表的數據必須存放一段時間,也就是應該有一個數據存儲

在弄清楚數據流圖的成分之後,就開始畫數據流圖了,首先畫出一個頂級數據流圖
在這裏插入圖片描述

從基本系統模型這樣非常高的層次開始畫數據流圖是一個好辦法。在這個高層次的數據流圖上是否列出了所有給定的數據源點和終點是一目瞭然的,因此它是很有價值的通信工具。

下一步應該把基本系統模型細化,描繪系統的主要功能。“產生報表"和"處理事務"是系統必須完成的兩個主要功能,它們將代替圖的"定貨系統”,如下面的一級數據流圖
在這裏插入圖片描述
接下來應該對功能級數據流圖中描繪的系統主要功能進一步細化。

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

因此,把"處理事務"這個功能分解爲"接收事務"、"更新庫存清單"和"處理定貨"三個步驟,這在邏輯上是合理的,如下面的二級數據流圖所示。
在這裏插入圖片描述
至此,一個詳細的數據流圖纔算畫完了。

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

例如,事務隨時可能發生,因此處理1.1(“接收事務”)必須是聯機的;採購員每天需要一次定貨報表,因此處理2(“產生報表”)應該以批量方式進行。問題描述並沒有對其他處理施加限制。對L2L2劃分自動化邊界的結果如下圖所示:
在這裏插入圖片描述

3.4. 數據流圖的分層

以上繪製數據流圖的步驟可以用下面這張分層數據流圖來表示,首先繪製最上面一層的頂級數據流圖L0L0,然後是第二層的一級數據流圖L1L1,再是最下面的二級數據流圖L2L2,理論上還可以畫出L3L3L4L4等等,但實際應用中畫到L2L2就可以了,不然數據流圖會過於複雜。
在這裏插入圖片描述

4. 數據字典 Data Dictionary,DD

4.1. 數據字典的概念

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

任何字典最主要的用途都是供人查閱對不瞭解的條目的解釋,數據字典的作用也正是在軟件分析和設計的過程中給人提供關於數據的描述信息。數據流圖和數據字典共同構成系統的邏輯模型,沒有數據字典數據流圖就不嚴格,然而沒有數據流圖數據字典也難於發揮作用,它們兩個要放在一起才能發揮作用。

4.2. 數據字典的內容

一般說來,數據字典應該由對下列四類元素的定義組成:

  1. 數據流
  2. 數據流分量(即數據元素)
  3. 數據存儲
  4. 處理

但是,對於數據處理,用其他工具描述更方便,通常是使用IPO圖或PDL。

典型的情況是,在數據字典中記錄數據元素的下列信息:

  1. 一般信息,名字、別名、描述等等;
  2. 定義,數據類型、長度、結構等等;
  3. 使用特點,值的範圍、使用頻率、使用方式(輸入、輸出、本地)、條件值等等;
  4. 控制信息,來源、用戶、使用它的程序、改變權、使用權等等
  5. 分組信息,父結構、從屬結構、物理位置記錄、文件和數據庫等等。

4.3. 定義數據的方法

數據是通過下面六種運算符由數據元素:

  1. 順序,即以確定次序連接兩個或多個分量;
  2. 選擇[][|],用於從兩個或多個可能的元素中選取一個;
  3. 重複{}\{\},用於把指定的分量重複零次或多次;
  4. 可選()(),即一個分量是可有可無的(重複零次或一次);
  5. 定義爲==,用於最終確定一個數據;
  6. 連接++,用於連接兩個分量

例如:某程序設計語言規定,用戶說明的標識符是長度不超過8個字符的字符串,其中第一個字符必須是字母字符,隨後的字符既可以是字母字符也可以是數字字符。則使用數據定義可以像下面那樣定義標識符:

  • 標識符=字母字符+字母數字串
  • 字母數字串=0{字母或數字}7
  • 字母或數字=[字母字符 | 數字字符]

4.4. 數據字典的用途

數據字典最重要的用途是作爲分析階段的工具。在數據字典中建立的一組嚴密一致的定義很有助於改進分析員之間以及分析員和用戶之間的通信,因此將消除許多可能的誤解。

數據字典中包含的每個數據元素的控制信息是很有價值的。因爲列出了使用一個給定的數據元素的所有程序(或模塊),所以很容易估計改變一個數據將產生的影響。

最後,數據字典是開發數據庫的第一步,而且是很有價值的一步。

4.5. 數據字典的實現

目前,數據字典幾乎總是作爲CASE"結構化分析與設計工具"的一部分實現的。在開發大型軟件系統的過程中,人工維護數據字典幾乎是不可能的。

如果在開發小型軟件系統時暫時沒有數據字典處理程序,建議採用卡片形式書寫數據字典,每張卡片上主要應該包含下述這樣一些信息:名字、別名、描述、定義、位置。

5. 成本/效益分析

5.1. 成本估算

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

爲了對比成本和效益,首先需要估計它們的數量。軟件開發成本主要表現爲人力消耗(乘以平均工資則得到開發費用)。當然成本估計不是精確的科學,因此應該使用幾種不同的估計技術以便相互校驗。下面簡單介紹3種估算技術。

  1. 代碼行技術
    代碼行技術是比較簡單的定量估算方法,它把開發每個軟件功能的成本和實現這個功能需要用的源代碼行數聯繫起來。估計出源代碼行數以後,用每行代碼的平均成本乘以行數就可以確定軟件的成本每行代碼的平均成本主要取決於軟件的複雜程度和工資水平。
  2. 任務分解技術
    這種方法首先把軟件開發工程分解爲若干個相對獨立的任務,再分別估計每個單獨的開發任務的成本,最後累加起來得出軟件開發工程的總成本估計每個任務的成本時。通常先估計完成該項任務需要用的人力(以人月爲單位),再乘以每人每月的平均工資而得出每個任務的成本。
  3. 自動估計成本技術
    採用自動估計成本的軟件工具可以減輕人的勞動,並且使得估計的結果更客觀。但是,採用這種技術必須有長期蒐集的大量歷史數據爲基礎,並且需要有良好的數據庫系統支持。

5.2. 成本/效益分析方法

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

其中,運行費用取決於系統的操作費用(操作員人數,工作時間,消耗的物資等等)和維護費用;系統的經濟效益等於因使用新系統而增加的收入加上使用新系統可以節省的運行費用。

因爲運行費用和經濟效益兩者在軟件的整個生命週期內都存在,總的效益和生命週期的長度有關,I 所以應該合理地估計軟件的壽命。爲了保險起見,在進行成本/效益分析時一律假設生命週期爲5年。

在以上條件的基礎上,可以從四個方面來考慮對成本/效益進行分析:

  1. 貨幣的時間價值
  2. 投資回收期
    所謂投資回收期就是使累計的經濟效益等於最初投資所需要的時間。
  3. 純收入
    純收入就是在整個生命週期之內系統的累計經濟效益(摺合成現在值)與投資之差。這相當於比較投資開發一個軟件系統和把錢存在銀行中這兩種方案的優劣。
  4. 投資回收率
    把資金存入銀行或貸給其他企業能夠獲得利息,通常用年利率衡量利息多少。類似地也可以計算投資回收率,用它衡量投資效益的大小,並且可以把它和年利率相比較,在衡量工程的經濟效益時,它是最重要的參考數據。
5.2.1. 貨幣的時間價值

通常用利率的形式表示貨幣的時間價值。假設年利率爲ii,如果現在存入pp元,則nn年後可以得到的錢數爲:F=p(1+i)nF=p(1+i)^n 這也就是pp元錢在nn年後的價值。反之,如果nn年後能收入FF元錢,那麼這些錢的現在價值是p=F(1+i)np=\frac{F}{(1+i)^n}

例如,修改一個已有的庫存清單系統,使它能在每天送給採購員一份訂貨報表。修改已有的庫存清單程序並且編寫產生報表的程序,估計共需5000元; 系統修改後能及時訂貨,這將消除零件短缺問題,估計因此每年可以節省2500元,5年共可節省12500元。

但是,不能簡單地把5000元和12500元相比較,因爲前者是現在投資的錢,後者是若干年以後節省的錢。假定年利率爲12%,利用上面計算貨幣現在價值的公式可以算出修改庫存清單系統後每年預計節省的錢的現在價值,如下表所示。

將來值(元) (1+i)n(1+i)^n 現在值(元) 累計的現在值((元)
1 2500 1.12 2232.14 2232.14
2 2500 1.25 1992.98 4225.12
3 2500 1.40 1779.45 6004.57
4 2500 1.57 1588.80 7593.37
5 2500 1.76 1418.57 9011.94
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章