從cmmi到cmm來看其變化
req從只有乙個pa叫rm，到兩個pa，分別是reqm、reqd
目前我們的需求開發就如在一間黑屋子打著手電筒在看你需要裝修的範圍，你看到乙個牆角牆上貼著白色的磁磚，鋪著藍色的地磚。你別以為客戶的整個房子的需求就是白磚藍地。那可只是個廁所。當你把全房子的燈都點亮，你再走一圈，你就會發出「原來如此」的感嘆，其時需求的難度不是問題，問題就是當你所有的燈都亮了的時候，專案進入測試階段的，這時候你發現返工很大，客戶不滿意，甚至對無關緊要的事情都在抱怨、惱火。
為什麼燈不能在專案前期點亮？
這盞燈在我看來就是業務專家，對行業從廣度到深度有切身體會的專家。當然對於一些小的專案不需要專家，專案經理應該要扛起責任來。
燈也不是說什麼時候亮就什麼時候亮的，足夠的時間是必須的，為什麼到了測試階段才豁然開朗？大部分的專案經理連需求範圍沒有摸清就開始摸石頭過河，我贊成對某些陌生業務的需求分析可以採用摸石頭過河的策略，但是前提是要搞清楚需求的範圍和方向。就像打帝國時代遊戲一樣，先造幾個兵，然後一人乙個方向出去探路，整個地圖都是黑的情況下，可以造農民、士兵一些基本的準備工作。等地圖一步步看清楚了，在決定策略，你靠海就多造船，你周邊物產資源豐富就多造農民、倉庫，物資多了就可以造更高階的**了。如果你地理位置險固比較容易守，就盡快先公升級。
兵法說要先謀而後定，需求開發不就是謀嗎？
軟體專案的需求分析
需求分析 在具體的研究需求分析之前，我們先了解一下軟體工程這個概念。軟體工程分為三個層次，過程層 方法層 工具層。在最基礎的過程層，最重要的就是一組被稱為關鍵過程區域 kpas 的框架 kpa的概念在討論cmm的書中有詳細的概念說明 關鍵過程區域構成了軟體專案的管理控制的基礎，並且確立了上下文各區域...
控制軟體專案的範圍變更
範圍管理是專案成功的基礎和重要因素。如果不能合理界定專案範圍，專案就無法啟動，無法進行專案管理，意外的變更將會隨時出現，專案也會返工 費用上公升甚至不能完成。專案範圍管理的核心就是控制專案範圍變更。目前，專案在實施過程中由於受到內外多種因素的影響，使得專案範圍的變更已經不可避免，也無法避免。所以，控...
實戰解析 專案目的和範圍
任何有明確時間約束和結果要求的事情我們都可以稱之為專案，專案培訓上老師會給大家講所謂的 qrt三重限制 產出 資源 時間，要想產出又多有好，那勢必投入更好的資源或者延長時間，這應該不太難理解。但是根據我的真實感受，還應該在再強調 目標 或者說動機 3 分鐘可以到現場進行救援！我們示範的專案名稱是 x...