在軟體專案的開發過程中，做三類計畫，第一類計畫（總體計畫）主要確定專案的範圍，專案完成時間。第二類計畫（發布計畫）是在總體計畫的基礎上，與客戶確定分階段推出軟體實現的業務功能，第三類計畫（開發計畫）是在發布計畫的基礎上，為保證如期發布業務功能而制定的計畫。
1．計畫的用途
總體計畫一般是開發方在初步了解客戶的需求後做出的對客戶的一種時間上的承諾，明確專案的範圍和規定專案完成的日期，一般專案的範圍使用user case表示。
發布計畫是根據每個user case的優先順序、每個user case的可能變更程度，由開發方和客戶共同安排的user case開發順序，並根據業務可執行性和盡快反饋要求，分階段制定要發布的業務功能單元和時間。如在開發物流系統中，我們確定了出庫、入庫、移庫、庫存報表、資料交換等use case。在制定發布計畫時，我們將出庫、入庫、庫存報表等use case作為乙個業務功能單元，制定發布時間。所發布的業務功能單元要交付給客戶評估，有可能的話，最好由客戶試執行。評估的結果作為檢驗是否滿足需求、需求理解是否存在差異、是否產生新的需求。
開發計畫是針對每個use case做出的開發計畫。同時，通過制定開發計畫也進一步對需求進行分析、確認，對技術難度進行評估。
2．計畫的制定
2．1發布計畫
在制定發布計畫時，應先確定use case 的實現順序，其原則如下：
l 客戶對業務的實現急迫程度高
l 業務簡單，不確定因素少
l 業務複雜，但可以確定的描述，不確定因素少
l 業務複雜，不確定因素多
l 實現技術複雜（使用其它技術無法替代）
確定實現順序後，暫時不考慮業務複雜不確定因素多的和技術實現複雜的use case。參考以前的專案或根據經驗估算實現每個use case的時間，制定發布時間和發布內容，交付制定開發計畫。對業務複雜不確定因素多的和實現技術複雜的use case進行再調研，在此過程中可能產生新的use case。制定過程中，先解決容易的，再解決難的，最終要明確每個use case的發布時間。制定發布計畫的過程應盡量的短，不能影響開發計畫的制定。同時要意識到，發布的業務單元有可能未被客戶認可，遇到此類問題可採取如下辦法解決：
l 如果專案的時間寬裕，應為每個發布點留有緩衝區
l 雖未被認可，但對開發方沒有不利的影響，可在不變更發布計畫、開發計畫的情況下，採取見縫插針的方法安排修改程式
l 對有不利影響，但修改程度比較小的情況，可暫停開發計畫，集中力量盡快修改
l 修改程度較大，或整個需求雙方分歧較大，應向客戶通報，重新制定發布計畫和開發計畫
2．2開發計畫
制定開發過程中，應對每個use case再細化，同時將已確定的use case集中，從實現技術角度考慮，劃分軟體任務。如可考慮將出庫、入庫業務功能中的業務規則，先進先出、食品應將距有效期最近的批次出庫等單獨作為乙個軟體任務。在確定開發任務後，與開發人員討論完成時間，同時專案負責人，還應考慮單元測試時間、業務單元模擬測試時間。確定的時間應與發布計畫中的業務單元發布時間比對，如超出發布計畫准許的時間，應修改開發計畫。
3．幾點注意事項
l 因最開始制定的發布計畫未覆蓋全部的use case，所以專案負責人應在制定發布計畫時切不可造成前線寬鬆後面緊張的情況，應盡量加快已明確的use case開發速度
l 在制定發布計畫時，應使用ken schwaber:scrum methodology中的關於需求複雜性、技術複雜性的係數，估算每個use case的時間
l 制定的軟體開發任務應盡量做到每天可以度量，以便保證計畫的順利執行
軟體開發的一點感想
這兩天，遇到工作中的兩個小問題，加深了我以前對軟體開發的看法。b 乙個是關於firefox崩潰問題的處理。b 其實，現在最難的就是 b 問題發生在 b 根據現象，我覺得問題應該是發生在firefox初始化時，需要連線到網路，譬如檢測firefox最新版。在定位問題後，我用firefox的安全模式 f...
軟體開發和版本維護的一點感悟和體會
從畢業到現在已經4個多年頭，在這個公司做的事情不能說一點鍛鍊的意義也沒有，只是指揮者沒智慧型，只是消耗員工的青春時光，所以打工的感覺累的很。最初是讓寫一些單獨模組的程式，比如系統啟動指令碼，晶元驅動，bsp，公升級模組等，後來直接丟過來乙個產品工程 讓我維護。說實話，這個責任是蠻大的，我自己也覺得能...
我對軟體開發的一點思考
但凡是搞 的 對軟體架構 設計模式 xp程式設計 極限程式設計 或是敏捷開發 重構 這些軟體開發的思想或方法都不陌生 但是它們之間究竟有什麼聯絡？在實際的開發過程應該如何做？才能構建乙個好的程式 簡單來說 開發乙個軟體的常規做法是 先設計整個系統的總體架構 架構包含一些 層 的思想 希望你了解 層 ...