軟體工程:如何開發軟體? 把它看成是一件工程。 那麼就會有一些工具、技術、方法，也有管理的議題。

Presentation on theme: "軟體工程:如何開發軟體? 把它看成是一件工程。 那麼就會有一些工具、技術、方法，也有管理的議題。"— Presentation transcript:

1 軟體工程:如何開發軟體? 把它看成是一件工程。 那麼就會有一些工具、技術、方法，也有管理的議題。
因為軟體的開發是多人一起從事，所以可以看成是一個專案。 既然是專案，就必須分工，也有工作產出銜接的問題、成本、工程、品質.....。 如果你是一個專案經理，那麼你要如何管理軟體開發專案？ 通常的情況：假設公司給你10個人，要你在6個月開發出某某專案。

2 軟體的特性 很抽象。 不易描述。 初一與十五不一樣。

3 使用者或業主提需求 通常都是功能面的描述,可以條列或文字敘述。 開發方會把使用者需求轉換成系統功能與效能規格 (得到系統需求規格書)。

4 系統功能規格如何得到? 好客提供 (可遇不可求) 開發方主動出擊： 1.發問卷收集功能。 2.使用者訪談。 3.以雛型展示收集功能。
　1.發問卷收集功能。 　2.使用者訪談。 　3.以雛型展示收集功能。 　4.分析使用者需求書。

5 系統的效能規格 系統必須能同時接受20,000萬個連線。 帳號登入後，半小時不動作，就斷connection。

6 重要的一點 系統功能與效能規格一定要得到使用方(或委託方)的認可。 Comitiment(取得協議)。

7 系統功能如何描述(1/2) 不同的角色 (role) 要有不同的功能 選課系統為例 對學生而言,提供下列功能：
　1.此系統可以透過瀏覽器來操作 　2.選課 　　(1)加退選。 　　(2)排序選課結果。 　　(3)學分數加總。 　　(4)課程介紹。 　　(5)即時顯示目前選修人數。 　　(6)列印選課結果。 　　(7)選課結果 告知。

8 系統功能如何描述(2/2) 3.其他 (1)可以反應意見。 對教務行政人員而言，提供下列功能： 1. 統計功能。 2. 列印功能。
　3.其他 　　(1)可以反應意見。 對教務行政人員而言，提供下列功能： 　1. 統計功能。 　2. 列印功能。 　3. 設定系統逾時的時間。 　4. 高年級的課程可以讓低年級在選課畫面看到的設　 　　 定。 Use Case 與 Use Case Scenario 。

9 use case diagram bar man 表示某一類使用者 (role) 。 actor 。 會在底下標明是那一類的使用者。

10 橢圓 表示使用案例 (use case) Recover a test question 名稱以動詞開頭(如果寫成英文) 。

11 從 bar man 連到 use case會有一條線
於橢圓形端帶有箭頭。 表示使用。 將所有的 use cases 以矩形包含起來，表示 system boundary，也就是從某一種使用者角色來看，這就是系統，而系統名稱是寫在左上角的一個小矩形內。

12 use case 與 use case 的關係 (1) Extended
　<<Extend>> 表示使用者在操作某一個use case 時，可以“選　 　　　用”其他use case。 (2) Included 　　．--- <<include>> 從某一個 use case (例如 A) 畫一條線 到另一個use case (例如 B)，箭頭出現在B端.表示 use 　　　case A 一定會啟用use case B 。 　　．--- 通常用來抽離多個use case 的共同部分，然後以一個 　　　usecase表示，然後所有use case皆 include 此 use case。 考試時間到 考試中斷 <<Extend>> 參與考試

13 use case diagram 考試子系統 考試時間終了 考試遇到中斷 <<Extend>> 參與考試 練習中斷
查詢成績 更新帳號 考試子系統 練習 Role:Student

14 use case scenario description
描述使用者與系統之間的互動行為。 通常採用一來一回的方式描寫。 Preconditions : 啟動這個 use case 的先決條件。 在寫 use case scenario 時，GUI 元素也可以寫出，例如按鈕、網頁選單、功能表選單，或寫”參考圖”。 對應的GUI 元素應該在使用者介面設計階段出現。

15 新增帳號的 use case Precondition : 以系統管理者的身份登入系統 ( use case login)
actorsystem 　1. 輸入帳號與密碼，以及帳號種類到系統。 　2. 檢查帳號與密碼是否符合規定的格式，若符合則顯示　 　　“新增成功的訊息”並建立帳號與密碼，若失敗，則顯示　 　　“失敗原因”，並要求重新輸入。 　3. 收到成功或失敗的訊息。 　＜註解＞帳號種類有兩種：(1)一般使用者(2)評量管理者。

16 與前一張slide有何差別 1. 系統管理者啟動”帳號管理”功能。 3. 系統管理者選擇”新增評量管理者或一般使用者帳號”功能選項。
Actor System 1. 系統管理者啟動”帳號管理”功能。 3. 系統管理者選擇”新增評量管理者或一般使用者帳號”功能選項。 5. 系統管理者鍵入帳號名稱 (login name) 及密碼 (password)。 2. 系統回應”帳號網頁”並列出所有帳號。 4. 系統回應”新增評量管理者或一般使用者帳號”網頁。 6. 系統建立新帳號，回應新增帳號成功的訊息。

17 需求規格書範例 以此為關鍵字，Google一下。

18 資料分析 (Data analysis) 針對技術需求規格書上的名詞進行分析，找出這些 名詞的定義。
資料字典 (Data Dictionary) 。 統計每一系的學生平均修習學分數，以系為單位，繪 製長條圖。 系 (系名,系代號) 。 學生(姓名,學號)，從學號要看得出系別。 平均修習學分數：系學生之修習總學分數除以系 學生人數。 長條圖。

19 程序分析 (process analysis)
假如有一描述，“學生可以使用帳號密碼登入系統，系統會進行帳號密碼檢查，若成功才能使用系統功能。若失敗就給一個錯誤訊息” 。 程序分析是針對動詞進行定義，這裡的定義是指將來我們要實作這個動作時要如何做。 使用帳號密碼登入系統：系統給一個要求帳號密碼的畫面 進行帳號密碼檢查：將使用者輸入的帳號密碼與資料庫裡的帳號密碼比對。 使用系統功能:把所有可用的功能呈現在畫面上。 給一個錯誤訊息：給一個訊息方塊,上頭有錯誤訊息。 資料分析與程序分析可以看成是系統初步設計。

20 有一個軟體有下列的功能， 請練習資料分析 資料分析 使用者給定多媒體簡訊後按送出,可以把多媒體簡訊送給手機。
使用者:userID 、 name 、帳號、密碼。 多媒體簡訊：MMS，會有格式，要找出來。 兩句有何差別 手機：3G的門號。 使用者給定多媒體簡訊後按送出鈕，可以把多媒體簡訊送給另一個使用者的手機。 使用者:userID、name 、帳號、密碼、 3G手機門號。

21 請練習程序分析 程序分析 1.使用者給定多媒體簡訊 : (1)假設多媒體簡訊可以用檔案來儲存，那麼就是系統要提供檔
　 (1)假設多媒體簡訊可以用檔案來儲存，那麼就是系統要提供檔 　　　案上載功能(而且限定是多媒體簡訊檔) 。 　 (2)假設無法以檔案型式存在，那麼系統就要能提供圖片檔、聲 　　　音檔上載以及文字輸入的功能，然後還要能整合成多媒體簡 　　　訊的串流格式(註：圖片檔、聲音檔也有格式限定)。按送出 　　　鈕 : 畫面上有Button 可以 Press。 2.把多媒體簡訊送給另一個使用者的手機： 　(1)假設已經向行動電話系統業者買了點數，系統業者提供API讓 程式呼叫，把多媒體簡訊送給另一個使用者的手機的動作就是 將多媒體簡訊串流 + 手機號碼 透過 API 送到 行動電話系統 業者。 (2)手機使用USB接在軟體執行的電腦。把多媒體簡訊送給另一個 使用者的手機的動作就是撥號，然後送出多媒體簡訊串流。

22 系統技術規格 把功能規格與效能規格拿來分析，針對無法了解如何做的部分，加以釐清,使可以implement(實作)。
同樣以選課系統為例，對教務行政人員而言，提供統計功能，但是統計什麼？針對那些資料進 行什麼處理？產生什麼輸出？與教務行政人員溝通之後，也許得到以下的一種答案，統計每一系的學生平均修習學分數，以系為單位，繪製長條圖。 此系統可以透過瀏覽器來操作，針對此，我們知道是Web Application，但是會有多重選擇： 　．方案1 Tomcat www server (JSP) + Linux + MySQL 　．方案2 Apache www server (PHP) + Linux + MySQL 　．方案3 IIS (ASP.NET) + Windows XP + SQL server 2005 方案評估。 訂定評估準則 (技術能力夠不夠,省不省錢,客戶要求.....) 。 進行評估(也許是用評分法) 。

23 設計 (Design) 設計出藍圖 (blue print)。

24 程序設計 主要是考慮每一個程序有什麼輸入資料，做 什麼動作，有那些輸出資料。 ．輸入資料從哪裡來?輸出資料到那裡去?
　．輸入資料從哪裡來?輸出資料到那裡去? 　．如果是物件導向的系統開發，就會以 　Object Sequence Diagram 來描述每個動 　作，當然就會有 Class Diagram 。 　．如果是 procedure-based 的系統開發,我們會使　　 　　　用 DFD (Data Flow Diagram)來描述動作。 系統架構設計

25 DFD 的四種圖示 (1) Entity , 外部實體 ．可以是使用者或是其他系統。 ．一定是名詞或名詞片語 (英文文法) Catalog
　　　．可以是使用者或是其他系統。 　　　．一定是名詞或名詞片語 (英文文法) Catalog 　 　　　　　Subsytem、Sales。 　　　．名詞短語 (中文文法)，影像處理單元。 (2) Data Flow Arrow (資料流箭頭) 　　　．表示資料流動的 Source 與 Destination。 　(3) Process 處理程序 　　　---> 拆解到function(函式,函數,副程序) 。 　　　---> unit。 　　　．一定是動詞或動詞片語 (英文文法) Encode Image，用 　　　　　動名詞也可能Image Encoding。 　　　．動詞短語 (中文文法), 對影像進行編碼 , 影像編碼 　　　　(相當於英文的動名詞)。 　(4) Store，儲存實體(檔案或資料表) 　　　．電源關閉,資料還在。

26 DFD 分成不同的Level Level 0 也可以稱為 Context Diagram，表示系統與外界的輸入輸出關係。

27 畫 DFD 時的注意事項 1. Process 有輸入就要有輸出。 2. Entity 與 Store 之間不能有 Data Flow。
3 Entity 與 Entity 之間不能有 Data Flow。 4. Store 與 Store 之間不能有 Data Flow。

28 DFD 的缺點 1. 無時間的順序。 2. 無決策點。 3. 可以使用活動圖或流程圖來補足。

29 系統細部架構設計（1/2） 以 procedure-oriented為例，系統會被拆解成許多procedure的組成。
例如 main() 下又分許多 procedures，每個 procedure 又呼叫其 他的 procedure。 這裡的 procedure 就是 function，函式將這些 procedures 畫出來就是系統細部架構圖，是系統的靜態觀點。 系統細部架構圖無法表達系統動態感，因此必須使用流程圖或者活動圖來表達系統的動態觀點。 因為活動圖可以表示動作的split(分岔)與merge(合併)，所以要表達系統的動態觀點，我們會使用活動圖。

30 系統細部架構設計（2/2） Split：在某一時間點分開動作 (multi-threads) 。
merge ：等待所有動作完成了才啟動某個動作活動圖 　　　　　(activity diagram)，系統的動態觀點就以系統動態 　　　　　圖表達。 單元設計 (unit design)其實就是function，函式的設計。可以用流程圖來表達，也可以使用演算法來表達。 ＜註解＞何謂模組(Module)？ 　　　　同一類的單元集合在一起就叫做模組。訊號處理模組， 　　　　也許又分成語音處理模組、影像處理模組。

31 資料庫設計 資料庫就是資料表的集合。 資料表由欄位構成。 欄位有資料型態或資料格式的問題。 資料表與資料表之間會有關連。
primary key , foreign key , unique ? , null ? 所謂資料庫設計就是設計資料表，以及資料表之間的關係 result : 資料表的定義，ER diagram (Entity Relation Diagram,實體關連圖) 。

32 使用者界面設計 (user inteface design)
系統功能以什麼方式呈現在畫面上，讓使用者可以access(觸擊)。 美學、平面設計、圖示、控制項...。

33 Views of a System 其實軟體工程各個流程階段所產生的文件都是在說明“系統長什麼樣子”，也就是不同的觀點。
　．使用者需求書是從使用者的角度。 　．use case 與 use case scenario 是系統與使用者如何互 　　動的觀點。 　．DFD 是一個資料流觀點。 　．因為沒有一個觀點可以完整交待一個系統，所以才會需要　　 　　許多不同的觀點就好像建築設計圖，有 top view、side 　　view。

34 系統實作 資料庫實作：把資料表設計所得到的資料表，以及資料表與資料表之間的關係，實作到一個資料庫系統。例如MySQL、Microsoft 的 SQLServer 。 　 ．使用者介面實作：coding 以完成所設計的介面。 　 ．單元實作(含單元測試),雖然我們可以再以另一個人再測試一遍。 　 ．系統整合。 　 ．實作時最重要的工作是coding,coding時要遵照coding standard 。 　　-- for( i=0;i<100;i++) {　 　 //... 　 　 printf.. //... 　 scanf... 　 //... 　 } 　 or 　 for( i=0;i<100;i++) 　 {　　 　 ....

35 系統測試 (由第三方進行,例如測試部門) ．系統功能確認 (Validation),也叫黑箱測試。
系統測試 (由第三方進行,例如測試部門) ．系統功能確認 (Validation),也叫黑箱測試。 ．確認與 use case 的符合程度。所以我們會在發展use case的時候，就會順便完成 test case。 ．不管 code 如何寫的，只管功能有沒有達成。 ．系統功能驗證(Verification)，也叫白箱測試。 ．目的在以各種可能的狀況，測出系統的局限或是 bugs 。 ．在系統細部設計階段發展test case 。 ．系統功能確認 (Validation)與系統功能驗證(Verification)是組織。 ．內部進行,也叫 alpha 測試。 ．另外有一種測試是在軟體真正release前，開放給外部組織或人員測試，叫Beta測試。

36 品質管理計畫 變數命名原則。 版本控制計畫。 程式撰寫規範。 註解撰寫規範。 需求審查、設計審查、程式碼審查、測試實例審查。