航向新世界

01.共通性與可變性分析。(commonality and variability analysis, CVA)
02.抽象概念與實作分離
03.軟體開發過程視角 (p11)
   概念：這種視角「呈現了所研究的領域中的各種慨念... 得出概念模型時應該很少或者不考慮實作他的軟體...」。這個視角要回答的問題是：「軟體要負責什麼？」

“品質是設計出來的，不是測試出來的？”
怎麼看怎麼奇怪。
難道設計就沒有缺陷，就能夠完美？
軟體開發不是只有 SD 做的事情才是設計。設計也是有缺陷。有缺陷就需要檢驗，然後修正，在檢驗...。這才是品質的改善。

Kanban
1. 可跨不同專案
2. 適用於各種環境; 並非只有軟體業
3. Kanban 的 value stream 更為細緻

迭代模型 vs 增量模型 vs 螺旋模型
 

增量模型

SRS 內容綱要分享聯結

當我們已經確定了系統改進的目標之後，系統分析者需要將這些目標轉換成為為了達成目標所需的功能性需求與非功能性需求的大綱。
功能性需求經常以滿足系統改進目標所需的輸入、流程、輸出以及儲存資料與控制等觀點來確認。
非功能性需求的實例包括效能、容易了解與使用；預算與節省費用；安全性與審核控制等等。

系統擁有者
系統使用者
系統分析者
系統設計者

在 Scrum, 我們會在 Sprint 活動中讓團隊的成員對每一個 User Story 進行預估.
期間若對 User Story 的目的不清楚, 則須請 Product Owner 再說明。
瞭解後再進行細化、拆解。之後團隊成員再對 User Story 下的 Task 進行開發的認領.

Good SRS, 軟體需求規格, SRS範本  <<SRS 指引>>  分享鏈結 
在軟體系統開發的過程中, 我們都會不自覺的寫出一些東西. 在剛開始工作的前幾年, 並不覺得寫出的內容有什麼問題, 隨著時間的過去, 回頭看看寫以前的東西, 發現每次寫的內容範圍都不一樣, 內容的層次也高高低低, 沒有個準. 幾年之後, 終於找到時間整理一下這些想法.

CheckItems



重要等級
人工/自動
分類
　
項目
　


 
 
完整性
CM
 
 


H
M
 
CM01
必須實現SDD
 


M
A
 
CM02
無引用的變數或方法必須刪除
Findbugs 可協助


 
 
 
 
 
 


 
 
一致性
CS
 
 


M
A
 
CS01
風格必須一致
由 CheckStyle 檢查或 使用 IDE 的 Formater 格式化


 
 
正確性
CR
 
 


M
A
 
CR01
Class 與 Public 方法, 參數必須有注釋
由 CheckStyle 檢查


H
M
 
CR02
方法名稱, 註解內容與實作責任必須一致
 


H
A
 
CR03
必須關閉已開啟資源 (如, File)
Findbugs 可協助


H
M
 
CR04
指標釋放後必須設定成空指標
 


H
A
 
CR05
實作出的模組相依關係必須與設計一致
JDepend 可協助


 
 
可修改性
MD
 
 


M
M
 
MD01
方法中必須只能有一個 return
 


 
 
可理解性
UN
 
 


H
M
 
UN01
方法命名必須有意義
 


H
M
 
UN02
參數命名必須有意義
 


 
 
健壯性
RB
 
 


H
M
 
RB01
方法必須採取防禦式編程 (考慮 Value 的合理性, 上下界, 量的合理性)
 


H
A
 
RB02
數值運算必須有考慮到"被零除"的情況
Findbugs 可協助


H
M
 
RB03
若有使用數值判斷, 必須考慮到數值得精確值與變數宣告的型態所帶來的不確定性的影響
 


H
M
 
RB04
必須考慮到取得的資料筆數會"非常多"的情況
 


H
M
 
RB05
不可在集合迴圈中變更集合的內容
 


H
M
 
RB06
對於各層級發生的異常或錯誤必須有適當的處理
 


H
M
 
RB07
If 判斷式必須完整; 對於非預期的 else 必須有適當的處理
 


 
 
可理解性
UD
 
 


M
A
 
UD01
不可存在 Magic String 與 Magic Number
由 CheckStyle 檢查


H
M
 
UD02
If 判斷式必須有意義
 


M
M
 
UD03
log 的等級與描述內容必須合理; 描述內容必需可理解; 加註的內容請見 log 檢查說明
 


 
 
可追溯性
TA
 
 


M
M
 
TA01
必須有紀錄程式碼異動歷史
 


　
　
可驗證性
VR
　
　


M
M
　
VR01
代碼的實現技術必須便於測試
定義於開發規範中