軟體過程管理的幾點體會
1）用例驅動
按照rup的理論，軟體開發過程是以架構為核心、用例驅動、迭代增量的開發過程。用例是rup（
rational unified process
，統一軟體開發過程
，統一軟體過程
）中非常重要的工件，用於描述系統終端使用者與系統互動的過程，是制定迭代開發計畫的惟一依據，並可直接轉化為測試用例。
用例從功能上等同於xp中的story，但是表現形式更正規、描述手段更豐富。在開發過程中，用例起到了指導設計、普及業務知識、統一業務術語的作用。用例確定了，就等同於確定了業務介面（biz inte***ce），即確定了業務介面的方法、異常（錯誤碼）；同時在一定程度上確定了業務介面的實現方式，即通過抽象類、幫助類等描述業務方法的實現過程。因此用例質量的高低在很大程度上決定了整個系統或專案的成敗，特別在專案團隊中整體缺乏業務背景的情況下。
用例重點不在於用uml描述用例之間的關係，而在其文字內容；用例的核心是描述參與者與系統的互動過程及其後置條件，從效果上看採用craig larman的兩欄式更好些。用例要起到指導沒有業務背景、缺乏領域知識的團隊成員進行設計、開發和測試的作用，因此必須詳細到足夠程度。對於複雜的用例，可以採用活**來描述狀態遷移。
寫用例的過程本身也是個迭代的過程，有些用例因為複雜程度較高、需求模糊、執行路徑較多等問題，在初期無法詳盡描述；可以採用迭代的方法來處理，不可能、也沒有必要一次就完整地描述清楚。 xp
中提倡用story的方法來描述需求，其目的是減少寫用例的時間；但是必須注意到前提是xp中的另外一條原則：使用者須在現場。因為使用者在現場，可以隨時進行交流，因此用例的描述更多時採用口頭方式進行。如果開發全過程中沒有使用者在現場，採用story方式是不明智的、也是行不通的。
2）迭代開發
迭代開發的目的是盡早確定系統體系架構、有效規避風險、及時獲取使用者的反饋意見等，其中要點：獲取使用者反饋、不斷地校正需求；及早發現風險，並把風險規避到每次迭代開發過程中；提高團隊士氣，避免因為開發周期過長導致人員過渡疲勞。
迭代開發的核心問題是合理制定迭代計畫。制定迭代計畫要以用例為單位，根據用例的優先順序、技術風險、使用者關注程度等條件將用例合理分配到各迭代過程中。對於較為複雜的用例，可以分配到多個迭代計畫中，逐步完善和實現。迭代計畫的制定應發揮使用者參與的積極性。
制定迭代開發計畫，對子系統或模組來說，應以2~3週為乙個週期；如果在時間範圍內，無法完成開發任務，則應該減少本週起內開發任務，絕對不要延長開發時間。如果這樣做了，勢必導致迭代開發計畫失去效果，並逐步喪失管理的依據和威信。
迭代開發周期之間的分界線應該清楚、明確，在每個週期內流出30%左右的緩衝時間、**重構時間、整合構建時間、使用者交流時間等。在每個週期結束時，應完成部署和acceptance test；如果有使用者在現場，應向使用者演示系統並獲取反饋意見。每次迭代結束時，都應該得到乙個可以輸出的可以執行的版本。
迭代計畫制定後應分解為開發任務並分派到人，按照scrum/xp的理論，這個過程應該由團隊成員決定，而不應該由專案經理或其他管理人員分派任務。這樣做不無道理，如果執行上沒有問題，可以照此辦理。任務分解的核心是：應盡量細化、按照每個人工作效率，分配的任務應確保在1個工作日內完成；任何超過一天的任務，都應繼續細化分解。這樣做的目的是確保每天下班後，**能按時提交並進行日構建。如果任務分解不夠細化，將導致日構建無法實現。另外細化的乙個好處是可以測量，切記無法測量則無法管理。
另外要特別注意，每次迭代過程中要保持設計和**的一致性，喪失設計和**的一致性必然導致開發過程的混亂。
3）日構建
日構建是開發過程的脈搏，至關重要；同時實現起來也是特別特別困難。微軟公司擁有一流的開發團隊，實現日構建尚且困難重重、頗費周折，可以想見日構建實現起來難度有多大。打個比喻，日構建就像雜技裡的高難度動作，身體虛弱的人想玩非得**不可；但是即便如此，日構建還是要實現。日構建體現了乙個公司、乙個團隊的綜合素質，綜合能力，是乙個團隊成熟度的體現。沒有日構建，微軟公司怎樣管理龐大的系統和**，怎樣保證開發質量，或許也走不到今天了。
技術上實現日構建沒有什麼問題，特別是b/s結構中各個層面都可以做單元測試；在c/s結構中，除gui層面的自動化測試比較困難外，其他層面也沒有問題。因此，如何實現日構建從本質上說是乙個管理問題，需要管理層採取嚴厲的措施，保證日構建的推行。例如微軟採用一些小的懲罰措施例如帖個豬頭等，對違反日構建的人員進行懲戒。
日構建的內容包括：**符合規範性檢查（check style、pmd）；unit test；acceptance test等，這些內容應全部採用自動化測試方式進行。測試結果應通過email方式通知相關人員；其統計結果可以作為管理依據（再次強調沒有測量就無法管理）。
日構建程式的建立是乙個團隊戰鬥力由若到強的必經之路，是乙個團隊無往不勝的必殺絕技。（或許這才是微軟的秘密。）
4）**詳查
按照統計分析結果，單元測試、整合測試只能發現60%左右的bug，而**詳查可以發現70%~80%的bug，並且效率更高。另外，**詳查可以發現不好的程式設計習慣、不良的**風格、不合理的設計或實現等諸多問題，這裡面有些深層次的問題是無法用自動化工具檢查出來的。**詳查也是微軟這樣一流公司的必備措施。
**詳查的另外乙個好處是促進交流，**review的過程也是乙個交流的過程；通過此過程，有經驗的程式設計師能夠言傳身教地將專案實戰經驗傳授給新手，能夠快速提高整個團隊的技術水平。
參考書目： 1
）微軟的秘密 2
）敏捷迭代開發過程craig larman3）
**大全（cc2） 4
）uml
和物件導向模式craig larman5）
敏捷開發過程kent beck
工具： 1）
checkstyle 2
）pmd 3
）cruisecontrol/anthill 4
）cvs/svn 5
）jira 6
）wiki
軟體過程管理的幾點體會（轉老大最後發的）
1 用例驅動 按照rup的理論，軟體開發過程是以架構為核心 用例驅動 迭代增量的開發過程。用例是rup中非常重要的工件，用於描述系統終端使用者與系統互動的過程，是制定迭代開發計畫的惟一依據，並可直接轉化為測試用例。用例從功能上等同於xp中的story，但是表現形式更正規 描述手段更豐富。在開發過程中...
關於軟體維護工作的幾點體會
關於軟體維護工作的幾點體會 一 一定要明確工作的內容，不確定的地方要及早提出質疑，每個人都要能夠用一句話表達自己對工作內容的了解。另外，維護工作內容中沒有提到的變更堅決不允許去做，多做了就是畫蛇添足。二 時間再緊也要進行專案業務的分析和理解，包括系統的業務背景，資料庫 表 間的關係，本模組的業務工作...
提公升軟體開發效率幾點體會
背景 進入9月份以來接手了兩個專案，乙個內網管理和 要求生成靜態html 乙個純資訊管理的。兩個專案如果正常計算人力都應該在5人月左右 都在20萬左右 可是我這邊總共才4個人 其中美工1人，開發人員3人 沒辦法只好我一人兼顧兩個專案，開發人員一人負責乙個專案。這次我的配置實現資訊管理 工作流 內容生...