目前分類：軟體工程 (18)

瀏覽方式： 標題列表 簡短摘要

01.共通性與可變性分析。(commonality and variability analysis, CVA)

02.抽象概念與實作分離

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

“品質是設計出來的，不是測試出來的？”

怎麼看怎麼奇怪。

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

Kanban

1. 可跨不同專案

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

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

 

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

SRS 內容綱要分享聯結

(繼續閱讀...)
文章標籤
軟體需求規格書 SRS

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

當我們已經確定了系統改進的目標之後，系統分析者需要將這些目標轉換成為為了達成目標所需的功能性需求與非功能性需求的大綱。

功能性需求經常以滿足系統改進目標所需的輸入、流程、輸出以及儲存資料與控制等觀點來確認。

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

系統擁有者

系統使用者

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

在 Scrum, 我們會在 Sprint 活動中讓團隊的成員對每一個 User Story 進行預估.

期間若對 User Story 的目的不清楚, 則須請 Product Owner 再說明。

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

Good SRS, 軟體需求規格, SRS範本  <<SRS 指引>>  分享鏈結 

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

(繼續閱讀...)
文章標籤
SRS 系統需求 系統規格

Mr.Y 發表在 痞客邦 留言(1) 人氣()

▲top

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

 

(繼續閱讀...)
文章標籤
Peer Review 審查

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

前言

軟體成本 = 設計 + 開發 + 維護 + 運作 + 文件

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top
前言 
程式開發人員對 log 應該不陌生.
(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

估算, 『粗估的計算』；

估算是一個科學. 估算需運作在一組有意義的背景資料上. 

(繼續閱讀...)
文章標籤
估算 預估 Story Point

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

Code Review 是不是多餘的?
如果你是汲汲於賺錢的老闆, 應該覺得這幹麻做, 浪費時間.

(繼續閱讀...)
文章標籤
Code Review

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

SA 不是 User 講什麼他就寫什麼. 應該要再深入的問幾個問題以了解 User 講的有沒有矛盾的地方。

否則用這樣的使用者需求寫出來的解決方案, "有好也不完全"。

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

引用 <<維基百科>>

在系統工程及軟體工程中，需求分析指的是在建立一個新的或改變一個現存的使用者作業時確定新系統(複數)的目的、範圍、定義和功能時所要做的所有工作(不一定是系統的工作, 也有可能是流程工作)。需求分析是軟體工程中的一個關鍵過程。在這個過程中，系統分析員必須確定顧客的需要。只有在確定了這些需要後他們才能夠分析和尋求合適的解決方法。

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

一個領域不是只在一間公司, 一個領域可以有許多公司在競爭. 例如, LCD 在台灣就有 4, 5 間公司. LCD 這個領域有不一樣嗎? 當然都一樣.

不同的是, 製程方式, 管理方式.

(繼續閱讀...)
文章標籤
DDD 領域設計驅動

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top

Code Review 是不是多餘的?
如果你是汲汲於賺錢的老闆, 應該覺得這幹麻做, 浪費時間.

(繼續閱讀...)

Mr.Y 發表在 痞客邦 留言(0) 人氣()

▲top