軟體設計評審檢查單
很多企業在做cmmi 3級，都要求了專案組要寫設計文件，做設計評審。按watts s. humphrey的建議，設計評審的工作量要大於設計工作量的1/2。很多企業也做了設計評審，但是很少發現實質性的問題。經過我的分析，發現缺少設計評審的檢查單是其中乙個很重要的原因，設計評審時專家使用的檢查單是企業設計經驗的總結，是企業的財富，代表了在企業裡軟體設計質量的價值觀。而我看到的多個企業的設計評審檢查單，要麼是過於理論，要麼純粹是對設計文件格式的檢查，都很難幫助評審專家真正的發現問題，這實際上是典型的「形式上達到了模型的要求，但實際上卻未獲得價值」，這種現象如果持續久了，勢必會降低大家做設計評審的積極性，難以使技術評審成為企業的文化，反而助長公司的形式主義。
於是根據我對ood的理解，設計了如下的檢查單，在此檢查單中，所有的數字其實可以根據公司的實際情況進行調整，所有的檢查項回答為否也並非代表一定存在問題，需要進行專家判斷。這些檢查項背後隱藏了oo設計的一些基本原則。
序號
檢查項
1
所有的功能需求與非功能需求是否都體現在了設計中？
2
在設計中是否增加了不必要的功能？是否為未來的變更進行了過度設計？
3
類的屬性是否超過了公共方法的個數的2倍?
4
類提供的公共方法是否超過了7個？
5
某個類的方法是否即執行了修改又執行了查詢？
6
方法的引數是否超過了3個？
7
每個方法估計的規模是否超過了200行**？
8
類依賴的物件是否超過了5個？
9
類繼承層次是否超過了6層？
10
是否有的子類並非父類的特殊種類，而是父類的角色？
11
是否存在某個基類不是抽象類？
12
繼承自非抽象類的關係是否合適？
13
是否存在某個介面，某些客戶僅僅使用其部分方法？
14
是否需要在執行時刻判斷物件的型別？
15
類的訪問許可權是否合適？
測試用例評審檢查單
序號 主要檢查項 1 需求規格說明書 是否評審並建立了基線？2 是否按照測試計畫時間完成用例編寫？3 需求新增和變更是否進行了對應的調整？4 用例是否按照公司定義的模板進行編寫？5 測試用例是否覆蓋了 需求規格說明書 6 用例編號是否和需求進行對應？7 非功能測試需求或不可測試需求是否在用例中列出並...
軟體設計模式 單例模式
單例模式，顧名思義，就是只能由乙個例項，那麼我們就必須保證 該類不能被複製。該類不能被公開的創造。那麼對於c 來說，他的建構函式，拷貝建構函式和他的賦值函式都不能被公開呼叫。但對於該私有的建構函式的構造時機上來說也可以分兩種情況來構造 只有當需要改類的時候去構造 即為懶漢模式 在程式開始之前我就先構...
軟體設計模式 單例模式
前篇 軟體設計模式 基礎 前篇 軟體設計模式 三種工廠模式 前篇 軟體設計模式 裝飾者模式 單例模式是建立型模式 2.單例模式的實現 3.例子 在實踐專案開發中經常會遇到一些物件，這樣的物件在全域性當中僅存在乙個就可以。如果出現多個。程式執行可能會失敗。或是記憶體上的管理問題。就是只需要乙個即可，比...