航向新世界

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
代碼的實現技術必須便於測試
定義於開發規範中

一人一副，一副牌 13 張
一局至少3人
玩法：
? = 這回合不計算。
無限大 = 最大值。
該回合若出現 0 與無限大, 則該回合無分數。張數算 1。回合數算 1。
其他比數字大者贏此回合。
分數計算：
1：以點數計分
2：以張數計分
3：以回合計分
延伸：
1：西洋棋
2：動物
3：戰爭 (海軍，陸軍)

前言
軟體成本 = 設計 + 開發 + 維護 + 運作 + 文件
其中，維護成本 = 了解 + 變更 + 測試 + 佈署上線
維護與運作是整個軟體系統生命週期最長的部分。

第一部  意義 

訊息不是終點, 不是全部; 訊息像是一把鑰匙, 將人帶往對的方向, 讓人用智慧以及訊息情境中的線索去抵達終點。

意義是來自於訊息、心智與情境脈絡的互動

聯想的網絡

關連性

意義不單取決於我們慣用的字詞定義

心智在接收新訊息之後，會判定這條訊息與當下的環境、我們的知識與看法有什麼樣的關連

這兩天又讀完一本小說, 我還蠻喜歡這種故事.
架構在真實的歷史上, 不會太過不真實.
上一本是他的第一部，這次我是讀第二部_科學之子.
翻開第一頁, 就一直到最後一頁... 真是糟糕..

混沌, 太極;
天地初生, 天清地濁, 分兩儀. 天象與地象;
象兩之陰陽;
天之四象有日月星辰;

前言 
程式開發人員對 log 應該不陌生.
我不知道外邊的世界的 log 都寫些什麼? 

呼... 終於看完末日之旅 上下兩集.
上集前 2/3 覺得令人感傷. 常常會想如果我是艾美, 我會有什麼感覺, 我會想些什麼..
後半部變得十分緊湊, 真的一口氣給他讀到完.
雖然最後, 是大屠殺. 但是以這樣的敘事, 應該是所有的煙鬼都消失了. 才會發現這份日誌.

估算, 『粗估的計算』；
估算是一個科學. 估算需運作在一組有意義的背景資料上. 
在軟體開發專案中，這邊建議可以導入 PSP 與 TSP。
專案總估算時間(days) = 系統規模點數 / 平均每人天消耗的點數