# 課程資訊
有同步線上課程
有實體課程
有作業
有專案
有工具實習

上課回答問題可加分
# 第一章 軟體危機
## 投影片內容
### 軟體迷思---Customer
(x) 僅提供一般性目標陳述就足以開始軟體開發
(x) 模糊或缺乏的需求可以在具體化時輕鬆納入或詳細說明

### 軟體迷思---Developer
(x) 軟體一經展示，工作就完成了
(x) 在軟體編寫完成並可供測試之前，無法評估其品質
(x) 軟體開發專案唯一的交付成果就是經過測試的程式碼
(x) 只要我的公司有良好的標準和明確的程序，我就不應該太擔心

### 軟體迷思---Manager
(x) 只要我的軟體工程師能夠使用最快速、最複雜的電腦環境和最先進的軟體工具，我就不應該太擔心
(x) 當我的進度延誤時，我需要展開一個應急行動：增加更多具備高技能和長期經驗的軟體專家，他們將幫助恢復進度！
## 影片內容
* 軟體開發失敗問題
* 無法達到使用者需求
* 軟體常當機
* 軟體過於昂貴
* 後續維護困難
* 遲交
* 無法有效率的使用硬體資源
* 軟體開發迷思破解
* 軟體開發應該在一開始規畫完畢，而非後來才加入
* 一開始便要訂定清楚的需求
* 軟體上市後，才是真正的開始
* 軟體的品質，應該在開發過程中就須確保
* 軟體的程式碼只是軟體的一部分
* 好標準跟流程不代表軟體一定會成功
* 軟體開發的環境只是決定是否成功的條件之一而已，危險性分析、預算規劃等都十分重要
* 單純的不斷加入更多專家對軟體開發的速度提升是有限的
* 寫程式是Ad hoc development(隨意的)，軟體開發是系統性的
* 軟體包含指令、資料結構、說明文件
* 軟體開發流程種類
* Waterfall life cycle(瀑布式開發): 循序漸進，完成某步驟時便不再回頭
* Prototyping(擬定雛形): 在開發前決定好軟體的樣貌
* Spiral model: 螺旋式循環各個開發步驟的模型

## 上課內容
1. 軟體開發的觀念及想法
* 程式碼模組化，模組內的東西不影響其他部分
* 注意變數命名規則
* 講究品質，必須通過單元測試、補全error handling，而非能動就好
* 善用git/GDB等工具
* 與客戶交涉，並決定具體需求

2. 開發軟體/寫程式的差異
* 開發軟體需要與客戶端交涉，且需要涉及、需求分析、架構設計、使用者介面設計、資料庫、單元測試、可擴充性
* 程式跟軟體並沒有絕對的大小關係
* 盡量不要用很快淘汰的框架或套件
* 程式碼要有可讀性，不要有資安漏洞

3. 軟體工程師需具備的知識與能力
* 版本控制工具的使用、溝通能力

# 第三章 軟體模型
## 投影片內容
### Process iteration
分成兩種
* Incremental delivery:
* 開發和交付被分成許多"Increment"
* 先開發重要的功能
* 一旦開始開發一個Increment，其他需求就暫時被凍結
* Spiral development
* 過程以螺旋形式表示，而不是作為一系列帶有回溯的活動
* 螺旋中的每個迴圈代表過程中的一個階段，且沒有固定的階段
* 風險在整個過程中都得到明確評估和解決

Incremental development是想到甚麼加甚麼
需求可能會一直新增上去 而不是一開始就決定好了 所以最後會變得很亂
但針對每個需求的開發 仍然遵照設計、實現和測試的步驟來執行
Spiral model 需求會在開發前訂好
接著不斷重複、設計、實現和測試
直到開發完成

## 影片內容
* waterfall model: 將軟體開發分成數個階段，完成階段後不回頭
* 優點: 穩定
* 缺點: 需求需一開始決定好且不常變動，故只適用於需求固定不變動的系統
* 適用範圍: 需求充分理解且在設計過程中變更相對有限時、大型系統工程專案
* 步驟:
1. 定義需求
2. 設計軟體
3. 單元測試
4. 整合
5. 營運與維護
* Evolutionary models(演進式開發): 設計、開發、驗證交錯並行；在開發的過程中不斷磨合真實需求
* 優點: 可以應對需求不斷變化的客戶要求
* 缺點: 結構脆弱
* 適用範圍: 小型或中型的互動系統、大型系統的某部分、壽命較短的系統
* 可以細分成以下兩類:
* 探索式開發: 邊做邊確定需求
* 丟棄式開發: 先做雛形以釐清需求，再重頭開始開發新的
* Componant-base software(元件導向軟體工程): 利用已經存在的元件以構建一個新系統
* Rational Unfied Process(UML 開發):

## 上課內容
**驗證(vertification): 是否正確的建構出符合規格的產品
確認(vaildtion): 是否正確的建構出使用者要的產品**

Tool: 工具，例如gccgdb,,pip等等
Workbench: 多個工作串在一起
Evironment:

# 第四章
## 投影片內容
### The Rational Unified Process (RUP，統一軟體開發過程)
由UML和相關流程工作中衍生而來

* 分成四個階段:
* Inception: 建立系統的業務實例
* Elaboration: 了解問題領域和系統架構
* Construction: 系統設計、程式開發和測試
* Transition: 在運行環境中部署系統

# 第五章
## 投影片內容
軟體管理所需步驟
* 提案撰寫
* 專案計劃和排程
* 專案成本估算
* 專案監控和審核
* 人員選擇和評估
* 報告撰寫和簡報
## 第六章
## 投影片內容
專案排程(必考)

風險管理:
* 風險識別
* 風險分析
* 風險規劃
* 風險監控

風險種類:
* 技術風險 (Technology risks)
* 人員風險 (People risks)
* 組織風險 (Organisational risks)
* 需求風險 (Requirements risks)
* 估算風險 (Estimation risks)

處理風險:
* Avoidance strategies: 降低該風險發生的機率
* Minimisation strategies: 最小化風險造成的影響

## 上課內容
專案管理活動:
1. Proposal writing
2. Project planning, schedualing, costing
3. Project monitoring, reviews
4. Personal selection and evaluation
5. Report writing and persentation

專案規劃:
1. Quality plan: 品質控管計畫
2. Vaildation plan:
3. Configuration management Plan
5. Maintenance plan
6. Staff Development Plan: 人才培育計畫

必考:
1. 計算最快專案時程: 用類似拓譜排序的概念，可以多人同時工作
2. critical path: 一天都不能delay的工作組合
3. 所需專案人數: 平行的最大人數

## 第七章
## 投影片內容
需求的種類(1):
* 使用者需求: 為客戶編寫的需求。使用自然語言描述
* 系統性需求: 一份結構化文件，詳細描述系統的功能、服務和運作模式

需求的種類(2):
* 功能性需求: 描述系統"應該提供的服務"，ex: 系統該如何作出反應、系統在特定情況下應該如何運作
* 非功能性需求: 關於系統提供的服務或功能的"限制條件"，ex: 時間、一般非特定領域的標準
* 領域需求: 跟系統的應用領域相關的特殊需求

撰寫使用者需求
* 編寫需求的指南
* 創建一個標準格式，並對所有需求使用它
* 以一致的方式使用語言。對於強制性需求使用「必須」，對於希望實現的需求使用「應該」
* 使用文字突出來標識需求的關鍵部分
* 避免使用電腦術語
* **需求應該陳述系統應該做什麼，而設計應該描述它如何實現這一點**

## 上課內容
功能性需求: 需指定軟體實際應該執行的功能和操作
非功能性需求: 指的是軟體的品質屬性和性能特徵，而不是具體的功能。例如性能、可用性、安全性、可擴展性、可維護性、可靠性等等
領域需求: 需求通常涉及特定行業或領域的規範和慣例

1. 功能性需求
2. 非功能性需求
3. 領域需求
4. 非功能性需求
5. 功能性需求
6. 非功能性需求
7. 領域需求

圖形模型:
1. Used case
2. Class diagrem
3. State machine
4. Interation diagrem
5. Activity

必考: 給定自然語言，寫成有系統性的需求


# 第八章 System Models
## 投影片內容
* System Models 可以幫助我們與客戶溝通與解釋
* 可以從不同的觀點來看一個系統

* 模型類型:
* Data Processing model:
* Composition model: 描述系統的組成
* Architectural model: 描述系統的架構
* Classification model: 將類似元件分類成同一個抽象物件
* Stimulus/response model: 描述系統對事件的反應
### Context models
* Context models(可以用Architectural model描述): 描述系統的外在環境 (非系統本身)，可以看出系統是如何跟外部環境互動的
* 通常是透過 Architectural model 描述各系統間的架構
### Behacioural model
* Behacioural model (Process model): 描述系統從輸入到輸出的行為，可分成兩類
* Data processing model: 描述資料是如何在系統中流動的，通常會使用 DFD 描述
* 該圖是 Data flow diagrams (DFD)
* 此時的資料是 order
* State machine model (狀態機): 描述系統是如何在不同狀態轉換的
* 狀態以節點來表示
* 事件以箭頭來表示
* 當事件發生時，系統狀態便會改變
* 應用: UML 中的 Statecharts
* 可以看到每個節點都是一種狀態 (例如waiting)
* 可以看到每個箭頭都是一種事件 (例如 Door close)
### Structural model
* 描述系統的邏輯結構
* 例如 單元-關係-屬性 模型
* 常見於資料庫設計，但不在 UML 定義中
* 可以當作就是資料庫系統中的 er-diagrem

### Object model
* 用來表示系統中有那些 object class (類似物件共同特徵的抽象化)
* 又可以細分為:
* inheritance models: 模型中的類別是由上而下、透過繼承產生的
* Aggergation models: 類別是由下而上、透過聚合產生的
* Interaction models: 描述了許多類別間的互動關係
* 表示物件之間互動的行為
* 使用Sequence diagram (又稱collaboration diagrems 或 interaction diagrams)

# 第11章
## 上課內容
系統可以分成四大類
* Data processing system
* Transaction processing system
* Event processing system: 透過事件trigger
* Language processing system: 跟自然語言處理有關

# 第12章
## 上課內容
* pair progremmimg: 每段程式至少會有兩個人負責
* 優點: 較能確保程式的品質，比較不容易出錯
* 缺點: 人力成本可能較高

exetreme progremming
CUsotmer incolvement(客戶參與): 使客戶直接到現場
Incremental delivery(逐步交貨): 高頻率的釋出小更新
People not procss: 使用pair progremmimg
Embrace change: 允許需求能被改變
Maintain sinplicity(維護簡單性): 重構

Language processing system 實例