需求獲取與分析
a)不要在需求獲取和分析過程中吝嗇你的時間，對需求的明確可以減少你以后設計和開發的改動，提高你所開發軟件的可用性。你對它的輕視只可能換來對你的產品修改、計劃延遲等方面的懲罰。
b)要使盡各種辦法，盡量多的獲取客戶的需求，主要的方法包括：仔細閱讀合同標書和市場資料、與客戶直接的談話交流、讓用戶觀看或使用原型界面提出意見。另外不要忽略內部客戶的一些合理需求如測試人員等。
c)進行正規的需求管理，如建立需求文檔或使用需求管理數據庫等。在文檔或數據庫中要保留每個需求的詳細描述及其來源，最好還能記錄一些其他細節信息（如用戶的一些原始描述等），另外別忘了確定每個需求的優先級。
d)在設計前組織你的設計人員開會進行需求理解和討論。由于閱讀文字性的信息容易造成一些誤解和歧義，最好讓需求制定者組織會議，給相關人員（如各子系統設計人員）講解需求并進行設計討論。這樣做有兩個好處，一是避免設計與需求出現偏差，二是激發設計人員產生初步的設計想法。
確定結構及系統設計
a)頂層設計必須要有多人及專家參與。一個好的設計方案不可能完全出自一個人的腦袋，它往往是經歷多次討論甚至爭論、多次改進與融合而最終形成的一個有創造性的妥協產物。但你要避免爭論的過分激烈而導致的負面效果。
轉貼于：中國項目管理資源網
b)一個好的設計應包含簡單的框架，細節隱藏其下。組塊和模塊是一個好的設計所具有的特征，在頂層設計里人們看到的是簡捷的框架和功能明確的組快，在每個組快內部又能發現一個簡單的框架和其他一些自包含的的組塊或模塊。
c)在系統設計時想想你的用戶將怎樣使用你的軟件工作。很多時候設計人員會習慣性地從技術角度考慮系統地布局和劃分，可這種技術上地合理有時可能跟使用上的合理是沖突的，所以此時考慮一下你的用戶將降低你今后修改的風險。
有關詳細設計
a)詳細設計沒有必要過于精細準確。目前對有關底層詳細設計是否需要以及它該詳細到何種程度還存在一定的爭論，但認為可以不要和必須寫得非常精確這兩種極端思想都是有害的。詳細設計的作用在于開發人員編碼前整理思路，同時讓別人通過審核詳細設計文檔檢驗你的思路是否正確，防止出現錯誤。
測試問題
a)繁雜但極富成效的單元測試。如果想將你的軟件質量提高到一個新的檔次，對開發的軟件模塊進行完整的單元測試是一個很好的途徑，它能使開發者對自己的代碼成果更加有信心。雖然一些軟件項目單元測試做的很少甚至沒有，并且產品在最終測試后也運行的不錯，但它只能保證在與最終測試環境類似的環境中運行是安全的，超出這樣一種環境范圍則可能充滿雷區。
b)必不可少的最終測試。如果你的項目受時間、人力等資源影響沒法進行過多的單元測試，那最終測試就成了你軟件產品的唯一質量保證，千萬別把這一保證也丟了，沒有它你的軟件產品就毫無質量可言。最終測試的另一大用處是通過它可以發現一些單元測試的漏洞，完善單元測試用例。
c)根據你的軟件特性選擇自動測試。自動測試如果能在你的項目中使用上，將是個不錯的消息，雖然目前的自動測試工具對一些特殊情況和特殊數據的細節處理略顯笨拙，但用它來檢驗產品的基本可用性和代碼修改的影響卻是高效的。有時自動測試還可能幫你發現手工測試幾乎不可能出現的錯誤情況，例如極短時間內觸發多個操作造成的沖突等。
有關重構
a)頂層結構的重新設計。通常當你的項目出現這種情況是非常不幸的，出現的原因一般是由于原來的結構不能支持新補充的特性而不得不進行修改。這種重新設計要注意兩點，一是時機最好選擇在一個大的工作階段開始時，二是在新結構中盡量移動原有代碼而不是編寫新代碼。
b)底層模塊的改進。由于當初編寫時的倉猝或考慮不周使得現有模塊存在這樣或那樣的問題并且難于理解，這種情況下進行重構改進是很有必要的。修改的方法通常為對已有代碼進行整理和注釋，增加模塊的封閉性和穩健性。
新技術的運用
a)評估新技術，確定它是否可以給項目帶來好處。合適的新技術可以提高產品開發效率和質量，判斷某一新技術對你的項目是否合適通常需要派專人或一個小組進行小范圍考察和驗證。采用新技術的時機最好選擇在項目開始時或項目的某些重要階段開始時，另外千萬別忘了培訓你的開發人員使用它。
b)避免幾種使用新技術的動機。一是為了學習新技術而在項目中使用新技術，這樣只能使你的項目變成一個實驗田，項目產品最終也成了實驗產品。二是不要指望使用新技術能拯救陷入困境的項目，如果一個項目陷入困境，它通常需要的是清晰和穩定，未知的新技術很可能導致更大的混亂。