《软体工程的实践》PPT课件.ppt

第14章 軟體工程的實踐 本章大綱 l14.1 能力成熟度整合模型 （Capability Maturity Model Integration） l14.2 CMMI 的架構 l14.3 極限編程（eXtreme Programming） l14.4 XP 的十二項實踐 能力成熟度整合模型(1/6) lCMMI的歷史 l1984年在美國國防部的支持下，卡內基美隆大學（Carnegie Mellon University, CMU）成立了軟體工程學院（SEI）；於 1986年11月，在Mitre公司的協助下，開始發展一套幫助軟體 業者，改善軟體流程的流程成熟度架構（process maturity framework），並於1991年發表了CMM模型。 l歷經近20年的沿革，SEI不斷地延展CMM意涵與適用性，如今 的CMMI模式包含了系統工程（Systems Engineering, SE）、 軟體工程（Software Engineering, SW）、整合產品與流程發 展（Integrated Product and Process Development, IPPD）， 以及委外作業（Supplier Sourcing, SS）四個專業領域。 能力成熟度整合模型(2/6) lCMMI的簡史： l1984：成立Software Engineering Institute（SEI）。 l1987：發表CMM技術報告初稿。 l1989：發表第一本有關軟體成熟度架構的著作。 l1991：發表CMM 1.0。 l1993/1994：發表CMM 1.1以及PSP（Personal Software Process）。 l1995：發表各種專門化的CMM，包括針對軟體採購（ SA-CMM）、系統工程（SE-CMM）、整合產品開發（ IPD-CMM），以及人力資源管理（People-CMM）。 能力成熟度整合模型(3/6) l1996：TSP（Team Software Process）發表。 l1997：新的品質管理標準，如EIA/IS 731出現；開始 CMMI整合計畫。 l2000：發表CMMI 1.0。 l2001：發表CMMI 1.1。 l2006：發表CMMI 1.2。 能力成熟度整合模型(4/6) lCMMI的內涵與精神 lCMMI本質上是一個專案管理模型，關心的是軟體 流程，而非流程背後的軟體產品。其結構化的專案 管理模型，可有系統地改善組織的（軟體開發）流 程。 l圖14.1可說明CMMI的觀點。 圖14.1 軟體流程與品質之關係 能力成熟度整合模型(5/6) l若要開發出高效率、高質量及低成本的軟體，就必 須從改善軟體生產流程著手。這是CMMI的基本信 仰，認為流程的能力，會影響到最終產品的品質。 因此，CMM大量借用許多全面品質管理（TQM） 與品管架構，作為改善軟體開發的基礎。 lCrosby的品質管理成熟度矩陣，請參考表14.1。 表14.1 品質管理成熟度矩陣 能力成熟度整合模型(6/6) lCMMI流程改善的目標，是要提升流程的能力；亦即流程本 身能夠產出預定之結果的能力。當流程能力提升時，軟體 開發的產出，即變得可預測或可衡量。 lCMMI定義了一套流程成熟度的評價模型，作為組織改善流 程所參考的標準或目標。 lCMMI對於流程改進的藍圖，如圖14.2所示。 lCMMI雖然關心軟體流程，但是它本身卻並不定義任何流程 ；它只建議你應得到什麼結果（what），卻不指示你該如 何做（how），或者由誰去做（who）。它所包含的，只是 一套共通的流程需求，內含最佳的軟體實踐綱領與實用的 知識指引，幫助採用它的組織，按部就班地進行流程改善 。 圖14.2 CMMI的流程改善方法： IDEAL Model CMMI的架構(1/13) lCMMI的能力成熟度分級 lCMMI提供了一個評定組織對於軟體開發現狀的架 構。若用階層式表述，由低到高可區分為五個成熟 度層級：初始（initial）、管理（managed）、定 義（defined）、量化管理（quantitatively managed），以及優化（optimizing），每一層級 都是上一層級流程改善的基礎，如圖14.3所示。 圖14.3 CMMI流程成熟度的五個 階段 CMMI的架構(2/13) l初始級的特徵 l組織通常沒有流程，或流程的穩定性很差，甚至是混亂 的。 l在這一等級的組織中，所謂的流程能力，只能用於評價 個人，而非組織。 l第一級成熟度組織的特徵包括： 過度承諾的傾向。 在緊急關頭放棄流程。 無法重複成功經驗。 結果不可預測。 CMMI的架構(3/13) l管理級的特徵 l組織已建立起專案管理的政策與實踐這些政策的程序， 以達成第二級成熟度所有流程領域的特定目標（ Specific Goal, SG）與一般性目標（Generic Goal, GG ）。 l第二級成熟度組織的特徵，是紀律、可重複的流程，如 ： 計畫的安排與進度追蹤是穩定的。 計畫的進行在有效的管控之下。 成功的經驗可不斷地重複。 異常狀況發生時無法有效地反應。 CMMI的架構(4/13) l定義級的特徵 l組織已達成第二和第三級成熟度所有流程領域的特定與 通用目標，對流程已有詳盡的瞭解與說明，並用標準、 程序、工具及方法來表現。 l第三級成熟度組織的特徵是標準、一致化的流程，即： 工程及管理的作業均已標準化。 組織有足夠的能力因應突發狀況。 CMMI的架構(5/13) l量化管理級的特徵 l組織已達成成熟度第二、第三和第四級所有流程領域的 特定目標，以及第二和第三級的一般性目標。對整體流 程績效有重大影響的子流程，會使用統計或其它量化技 術來控制這些流程。 l第四級成熟度組織的特徵，是量化、可預測的流程，如 ： 整個流程都可被量測。 組織能夠預測出可能發生的異常狀況。 CMMI的架構(6/13) l優化級的特徵 l組織已達成成熟度第二至五級所有流程領域的特定目標 ，以及第二和第三級的一般性目標。根據對流程變異共 同原因的量化瞭解，持續進行流程改善。 l第五級成熟度組織的特徵是持續改善，如： 整體組織不斷地努力改進流程，以避免異常狀況的發生，最 終改進了流程的效能。 CMMI的架構(7/13) l流程領域 l所謂流程領域（Process Area, PA）是指一組同屬於某領域 而彼此相關的實務（practices）。當共同執行時，可達成一 組目標（goals），而這些目標對該領域的改善是重要的。 l第二級成熟度所涵蓋的流程領域包括： l需求管理。 l專案規劃。 l專案稽核與控制（project monitoring and control）。 l供應商協議管理（supplier agreement management） 。 l度量與分析（measurement and analysis）。 CMMI的架構(8/13) l流程與產品之品質保證（process and product quality assurance）。 l構型管理。 l第三級成熟度所涵蓋的流程領域包括： l需求發展（requirement development）。 l技術解決方案（technical solution）。 l產品整合（product integration）。 l驗證。 l確認。 l組織流程專注（organization process focus）。 CMMI的架構(9/13) l組織流程定義。 l組織訓練（organization training）。 l整合專案管理。 l風險管理。 l決策分析與解決方案（decision analysis and resolution ） l組織環境之整合（organization environment for integration）。 l團隊整合（integrated teaming）。 CMMI的架構(10/13) l第四級成熟度所要求的流程領域包括： l組織流程績效（organizational process performance） 。 l量化專案管理（quantitative project management）。 l第五級成熟度所要求的流程領域包括： l組織創新與推廣（organizational innovation and deployment）。 l根源分析與化解（causal analysis and resolution）。 l上述這些流程總結起來，可分別歸屬於軟體開發的 四個面向：專案管理、支援、工程，以及流程管理 ，其分類明細如表14.2。 表14.2 流程領域之分類 圖14.4 CMMI流程領域的內容 CMMI的架構(11/13) l流程領域的描述 lCMMI流程領域之內容，依照其重要性，由三種層級之資訊 所組成，分別是必要的（required）、期望的（expected） 與助益的（informative）（如圖14.4）。 l必要的層級所描述之組件，構成模型和該流程的改進基 礎。 l期望的層級之組件，雖然也是流程改進所需要的，但是 允許在某些情況下省略。 l助益的組件構成模型的主要部分，為流程改進提供了有 用的指導，在許多情況下，它會對必要和期望的組件提供進 一步說明。 CMMI的架構(12/13) lCMMI的兩種模型表示法（如圖14.5 ） l階段（staged）式模型： l特色在於將組織流程的改善區分為一系列成熟度等級 ；每一等級有一組對應的流程領域，指出組織應改善 的流程重點。 l階層式表述的優點是可以被評鑑，取得外部的認可；缺 點則是缺乏彈性，不能量身訂作。 l連續式模型： l根據組織當時的需要，選擇個別流程加以改善，個別流 程可單獨評價其等級，因此使用上更具彈性，更能適合 客觀的需要。 圖14.5 一個模型、兩種表示法 CMMI的架構(13/13) l連續式模型的好處，是給予組織在流程改進時更大的自 主空間，不必受到成熟度等級的嚴格限制；缺點則是若 缺乏指導，組織很可能忽略了關鍵流程間的相依關係， 使得片面實施某些流程的改善，缺少其它流程的支撐， 而變成空中樓閣。 l以上兩種表示法（連續式和階層式），在邏輯上是 等價的，雖然描述的機制不同，但皆可達到相同的 改善目的。 極限編程(1/5) l極限編程（XP）雖是一套新的軟體開發方式，但其具體實踐則來自於 許多早已存在的方法；只是這些原本散落在各處、獨立存在的方法， 經由XP用一種有機的方式加以整合，形成了一種特殊的工作模式。 lXP之所以如此不同，在於它對許多傳統熟知的軟體問題，如時程延誤 、需求誤解、品質不佳等，抱持截然不同的看法。 l傳統軟體工程方法為了避免專案後期的高成本，利用各種管理手段， 設法將錯誤所造成的成本壓縮（如圖14.6(a)），導致的結果是增加了 流程的負擔，使得專案的平均資源投入增加（如圖14.6(b)）。但是預 算的壓力與人力資源的限制，又將這些成本向下壓（如圖14.6(c)）， 於是最終的結果又回到原點，導致時程的延遲與成本的上升（如圖 14.6(d)）。 圖14.6 採用防堵的品管思維所可 能造成的成本變化 極限編程(2/5) l整體而言，XP是一套輕量級的軟體開發方法論；刪 除多數重裝流程所要求、不必要的文件或產出， 認為那些只會造成人員的分心，並拖慢軟體開發速度 。 l面對多變的軟體開發環境，強調適應勝於預測 ；強調適時、適當的（Just In Time, JIT）計畫與 設計，勝於事前詳盡的規劃與安排。 l認為軟體開發是人與人的合作，強調人本導向勝於流 程導向；成功的軟體開發應強化人的長處、避免短處 ，突顯人在軟體開發中的角色。 極限編程(3/5) lXP的核心價值主要有以下四項： l溝通：許多軟體開發問題，往往是由於開發者與顧客之間溝 通不順暢所造成的。 l簡單：儘量保持程式的簡單化，只要它能工作即可。不要製 造多餘的編碼（或設計）庫存；這樣一來，當改變來臨 時，所付出的代價最小。 l回饋：透過快速開發與交付，儘快獲得用戶的回饋，使得開 發人員能夠確認自己的成果，符合使用者的需要。 l勇氣：這是最重要的核心價值。XP強調要擁抱變化， 包含從用戶來的回饋與設計的重整；要勇於對自己的程式進 行修改，丟掉壞的程式碼。 極限編程(4/5) lXP的理論體系與實踐（如圖14.7） l四項基本原則是： l快速回饋：愈快回饋就愈有用。 l以簡單為假設：拒絕複雜的事前設計，只在需要時才將 複雜度加上去。 l漸進式開發：不要相信一次就能夠成功地完成一個大的 開發。 l擁抱變化：面對改變時，應該接受而非反對。 圖14.7 XP的理論體系 極限編程(5/5) l次要的指導原則包括： l教導學習。 l少量的初期投資。 l為勝利而遊戲（play to win）。 l具體實驗。 l開放、誠實的溝通。 l順從人的本性，而不是去對抗它。 l接受責任。 l視情況調整。 l輕裝旅行。 l誠實地度量（measurement）。 XP的十二項實踐(1/17) lXP的十二項實踐如表14.3所示，其意涵分述 於後。表14.4 XP的十二項實踐 XP的十二項實踐(2/17) l測試驅動（test-driven） l測試驅動是XP的核心思想，強調先測試，再編碼；亦 即未有程式，先有測試。在編碼開始之前，先將測試案例寫 好，而後進行編碼，直至通過所有的測試案例。 l測試先行的好處： l知道哪些地方可能出錯後再來開發程式，可以讓思考更 周延，避免後來許多不必要的除錯與改正的工夫。 l可用來檢驗簡單設計是否落實。任何程式功能（或片段 ）如果沒有被某個測試用到，就是多餘、不必要的。 l可給予程式開發一個清楚的圖像或定義。 XP的十二項實踐(3/17) l搭檔編程（pair programming） l搭檔編程的開發方法，是兩個程式設計者共用一台 電腦、一個鍵盤與滑鼠，所有的程式都由兩人共同 創作。搭檔兩人之間的關係是動態的，其中個人的 角色可以分別是策略者、執行者、驅動者或夥伴關 係。 l搭檔編程的優點如下： l更有紀律，避免惰性。 l更好的程式碼：持續地編碼審查，產生更好的設計、更 少的臭蟲。 l搭檔的開發流程更有彈性，能夠應付臨時的打岔，一人 處理而另一人繼續工作。 XP的十二項實踐(4/17) l增進士氣：搭檔開發比個人單打獨鬥更有趣。 l更有信心去增加或修改系統，促使軟體測試與程式重構 （refactoring）的實踐。 l增進集體擁有意識：輪換搭檔可提升程式碼為集體所有 的共識。 l教育訓練：輪換搭檔可將有用的知識散播給整個團隊。 l團隊向心力：搭檔可讓人更快熟識彼此。 l可確保XP的編碼標準、原則與實踐的落實。 XP的十二項實踐(5/17) l簡單設計（simple design） lXP認為設計不是一次性、事前可以完成的工作，因為需求經 常變化，為了減少變更所帶來的損失，所以根據最小投資原則 ，只進行最少、必要的系統設計。 l所謂簡單的程式應滿足以下原則： l通過所有測試。 l無重複贅碼。 l能夠清晰地陳述開發者的意向。 l只包含最少量的程式類別與方法。 l簡單設計帶來許多優點，因為簡單所以易於瞭解，因為容易瞭 解故容易修改。 XP的十二項實踐(6/17) l程式重構（program refactoring） l程式重構是指在不改變系統行為的前提下，重新調 整、優化系統內部的結構，以減少複雜度、消除冗 餘、增加靈活性或提高系統的性能。 lXP重視重構，並認為應該經常進行，但也不會為 了重構而重構。只有當系統有需要時，重構才會發 生。通常兩個最可能進行重構的時間點，一個是某 項系統性能的實現前，一個是該性能實現後。 XP的十二項實踐(7/17) l系統隱喻（ system metaphor） lXP利用隱喻來取代事先詳細的架構設計。隱喻的角色類似 於（系統）架構的說明，但是缺乏精確的細節。 l隱喻給予團隊一個共同的圖像，描述既存的系統如何運作， 以及未來的發展方向，包含新元件要以怎樣的形式加入到哪 裡。 l系統隱喻通常包含一些可參照和比較的程式類別與設計樣版 。 l隱喻不必一定要非常完美；讓每一個人都能瞭解系統 如何組裝與運作，是更重要且關鍵的一件事。 XP的十二項實踐(8/17) l集體擁有（ collective ownership） l類似於開源碼（open source）的開發模式，XP團 隊的每位成員都有權利更改任何程式碼，由全體成 員對所有的程式碼共同負責。不過，雖然程式碼歸 全體擁有，但並非意味開發者可以推委責任。 lXP的規則是：誰打破的，誰負責修理。開發 者仍應負責其程式的正確性與錯誤的修改。 l集體擁有強調的，是所有人都有責任。如果某人的 程式碼有誤，而另一個人知道了，就應該協助進行 修改。這是一種文化，需要極端（extreme） 的紀律來落實。 XP的十二項實踐(9/17) l持續整合（continuous integration） lXP提倡程式在通過單元測試後，一天之中多次進行系統整合 ，且隨著需求的改變，不斷地進行迴歸測試。 l頻繁整合會使得團隊隨時擁有一個最新、穩定的版本可以參考 ，簡化了構型管理的問題與複雜度。同時任何整合失敗，必定 是由於最後一次修改之程式碼所造成的，所以可立刻進行偵錯 。 l持續整合讓團隊得以保持一個穩定的開發速度，避免傳統方法 在走走停停兩個鐘擺之間來回擺盪，以及在最後一刻系統整合 失敗的惡夢。 l頻繁整合使得任何可能造成整合失效的原因變得明顯，讓開發 人員隨時瞭解他人的進展，以及介面溝通的方式。 XP的十二項實踐(10/17) l編碼標準（code standards ） lXP的精神是減少其它不必要的文件，儘量透過軟體 程式本身進行溝通。為了達到這個目的，程式編碼規 範就變得很重要。唯有透過一致性的標準，才能降低 溝通與失誤的成本。編碼標準讓程式碼保持一致性， 並且容易閱讀與重構。理想的目標，是讓程式碼看不 出來是由誰撰寫的。 l編碼標準的參考作法： l變數名稱必須是有意義的。 l名稱的屬性最好與其所代表的動作一致。 l儘量簡短的物件方法。 l短的程式註解（用程式本身而非依靠註解來讓他人瞭解 ）。 l儘量利用工具、樣版等來協助並驗證，以確保標準的落 實。 XP的十二項實踐(11/17) l小型發布（small release） lXP的核心價值之一是回饋。因此強調軟體開發應 於很短的週期內，以遞增方式發表軟體開發的結果 ，從而及時地獲得用戶的回饋。 l小型發布的辦法，是很快地先開發出一個簡單、可 以運作的系統，然後每隔一個短時間循環，發布一 套新的軟體版本（如圖14.8）。 l小型發布的另一目的，是便於衡量專案的進展。小 型發布使每個里程碑之間距離縮短，更易於掌握軟 體開發的真實進度，以便於安排當下的計畫並控制 風險。 圖14.8 XP的小型發布流程 XP的十二項實踐(12/17) l計劃遊戲（planning game） l由於XP強調調適（adaption）勝於預測（ prediction），所以它的專案計畫比傳統輕鬆許多 。不需要在事前確認完整的工作計畫，而是透過計 劃遊戲，先產出一個初步規劃構想，然後當事情更 清楚時，再逐漸修正它。 lXP採取多階段、多循環的階段交付開發策略，所 以其計劃遊戲分為兩種： l發布計畫（release plan）： 其理想的間隔時間長度大約是25個月。 決定哪些需求要在下一次系統發布之前完成，以及何時實現 ，由顧客與開發者共同商討決定。 XP的十二項實踐(13/17) 發布計畫的遊戲流程，如圖14.9所示。 l循環計畫（iteration plan）： 其理想的間隔時間是13週。 只有開發者參加，主要是決定該循環內要完成哪些工作與任 務分配。 lXP的一個循環，包括四項活動：計劃、設計、建 構，以及測試開發完成的故事。當前一循環結束時 ，即可進行下一循環的計劃會議。此時，參考前幾 個循環的平均開發速度，從計畫的範圍裡，挑選適 合的故事，納入下一循環要開發的故事清單中，時 間限制大約為13週。 圖14.9 發布計畫的遊戲流程 XP的十二項實踐(14/17) l一個團隊（one team） l一個團隊原名為顧客駐點，係要求顧客隨時可以被接觸到 ；亦即顧客應在開發團隊旁邊，或者開發者留在顧客的旁邊， 以便於隨時可以接觸與討論。 l一個團隊表明： lXP的成功倚賴良好的團隊合作。 l顧客是開發團隊的一部分，而專案的目標是共同的責任。 l開發是一個橫跨整個團隊的對話。 l這是一個彼此合作發明與溝通的遊戲。 l面對面是最有效的溝通。 XP的十二項實踐(15/17) l團隊成員願意用最少的成本、等待與中斷來配合他人。 l最好整個團隊在同一地方工作。 l持久步調（sustainable pace） l持久步調原名為每週工作40小時，其精神是強調工作品 質與符合人性。所以不加班、不超時工作，是其實踐的一部分 。 l除了人性的理由之外，這項實踐背後其實隱含更深層的意義： l軟體開發是一場馬拉松比賽，不是短期的衝刺。 l勞累與壓力會降低生產力。 l管理者有責任設立合理的工作環境與專案目標。 XP的十二項實踐(16/17) l超時工作是專案出現嚴重問題的一項徵候，這時該調整 的是計畫本身。 l團隊應該落實執行已確認的安排。 l各項實踐之互補綜效 lXP的實踐可分為三環，由內而外分別是：測試 驅動、程式重構、簡單設計、搭擋編程、集體 擁有、持續整合、系統隱喻、編碼標準，以及 計劃遊戲、小型發布、一個團隊、持久步調。這 些實踐彼此之間形成互補的綜效，如圖14.10。 圖14.10 各實踐彼此間之互補綜效 XP的十二項實踐(17/17) l綜合而言，XP代表的是一種輕量級的方法，較少 強調流程，更多注重人的能力與團隊合作；更簡化 的分析與設計，但更多可執行的程式碼；不注重正 式的計畫，但會根據情況隨時做短期規劃；不注重 正式的需求文件，更注意的是與顧客的互動與溝通 。 CMMI vs. XP(1/3) lCMMI與XP是目前軟體工程發展最具代表性的兩個主題，但也是很難 討論的題目；贊成者與反對者都有，並且兩者目前各自都還在繼續發 展與改進。 lCMMI與XP代表兩種不同的典型；一個強調管理，而另一個強調技術 能力。 l強調管理者以流程為軟體工程的核心（process-oriented），認為專 案成敗決定於流程的好壞，如何提升流程能力因此成為重點。 l強調技術者以人為軟體工程的核心（people-oriented），人的能力成 為決定成敗的關鍵因素。 l這兩者誰是誰非，或者熟輕熟重，是一項值得個人去體會與深思的問 題。 CMMI vs. XP(2/3) lCMMI最根本的問題，是假設軟體開發的性質類似於製造業，將它 視為系統化、可重複的流程，因而全面採用後者的品管架構來指導 前者。但事實上，軟體開發畢竟在許多地方與製造業不同（例如， 人的效能與變異性對軟體開發中所造成的影響，就遠大於製造業） ，所以這樣的套用會付出許多額外的成本；除非這項投資可透過後 續重複性的利用加以回收。 lCMMI的迷思之二，是提升流程的可預測性並不一定等於提升軟體 的品質。基於控制的思維，一般組織為了降低流程上的變數， 以符合CMMI的要求，勢必得犧牲其它東西作為交換。期望好的流 程帶來好的產品，基本上只是一個假設。因為流程本身仍然要靠人 來監督，而執行監督的人必須有足夠的能力、時間和經驗。倘若組 織的配合與支援不夠，或者人力、時間與資源的投入不夠充足，則 兩者之間甚至可能變成負相關。 CMMI vs. XP(3/3) lXP假設專案永遠處於變動之中無法預測，所以事前的設計是無用的 ，事前的規劃是不必要的，這些思考有其一定的道理，但並非永遠適 用。 lXP假設軟體開發唯一的角色就是程式設計人人都是程式師。這與 今日社會專業分工的思想不合。畢竟在軟體開發團隊中，至少需要好 幾種不同的任務與技能，如溝通與表達、分析與設計、程式開發等。 一般人很難同時擁有數種專長，這是為何需要專業分工的原因；分工 可帶來專注，以及工作品質與效能的提升。 l再來是管理上的問題。XP的專案協調與管理，主要依賴直接的人際 溝通（例如，與顧客交談而知悉其需求）。這樣的模式當團隊變大、 專案問題變得複雜時，溝通的成本必然升高。 l此外，某些XP實踐的背後也有其假設。 結語(1/2) lCMMI有兩種用途，一是用來改善組織的流程能力，一 是用來評鑑。後者之於CMMI要比前者重要得多。傳統 以來，軟體公司的管理一直缺少一套客觀的能力標準， 可用以比較或評鑑；而CMMI在推動這件事上，可說非 常成功。 lCMMI當然有其問題，不論流程的品質再怎麼努力 ，也並不等於產品的品質。倘若工程師的能力不足 ，一個很糟的軟體設計，依然可以通過層層關卡被交付 到用戶手中。而在這一點上，CMMI完全無能為力，這 是其先天的限制。 lXP或許掌握到真正問題的核心：工程師的能力與素質 。所以它將軟體開發的重心放在人的身上，所有的作 為都朝向支援而非妨礙工程師的生產力。 結語(2/2) l既然XP的重心落在人的身上，所以XP的實行是有條 件的：人的能力。無論是測試驅動、簡單設計、重構 或搭檔編程等，實行者都需要具備一定程度的能力與 訓練，才能掌握技巧做好工作，尤其是需要具備一定 程度的物件導向設計與開發能力。 l軟體開發是一個持續溝通與協商的過程，成功的軟體 專案需要每一方面的配合，以及多面向的知識與技能 。CMMI和XP都是好東西，但是需要知道如何應用， 否則專案依然會陷入危險。 1C4G7JbMePhTkWnZr$u*x+A2E5H8KcNfQiUlXp#s%v)y0B3F6IaLdOgSjVmYq!t*w-z1D4G7JbMeQhTkWoZr$u(x+B2E5H9KcNfRiUmXp#s&v)y0C3F6IaLdPgSjVnYq!t*w-A1D4G8JbMeQhTlWoZr%u(x+B2E6H9KcOfRiUmXp!s&v)z0C3F7IaMdPgSkVnYq$t*x-A1D5G8JbNeQiTlWo#r%u(y+B2E6H9LcOfRjUmXp!s&w)z0C4F7IaMdPhSkVnZq$t*x-A2D5G8KbNeQiTlXo#r%v(y+B3E6I9LcOgRjUmYp!t&w)z1C4F7JaMdPhSkWnZq$u*x-A2D5H8KbNfQiTlXo#s%v(y0B3E6I9LdOgRjVmYp!t&w- z1C4G7JaMePhTkWnZr$u*x+A2E5H8KcNfQiUlXo#s%v)y0B3F6I9LdOgSjVmYq!t&w-z1D4GbNfQiTlXo#s%v(y0B3E6I9LdOgRjVmYp!t&w-z1C4G7JaMePhTkWnZr$u*x+A2D5H8KcNfQiUlXo#s%v)y0B3F6I9LdOgSjVmYq!t&w-z1D4G7JbMePhTkWoZr$u(x+A2E5H9KcNfRiUlXp#s&v)y0C3F6IaLdOgSjVnYq!t*w-z1D4G8JbMeQhTkWoZr%u(x+B2E5H9KcOfRiUmXp#s&v)z0C3F7IaLdPgSkVnYq$t*w-A1D5G8JbNeQhTlWo#r%u(y+B2E6H9KcOfRjUmXp!s&v)z0C4F7IaMdPgSkVnZq$t*x- A1D5G8KbNeQiTlWo#r%v(y+B3E6H9LcOgRjUmYp!s&w)z1C4F7JaMdPhSkVnZq$u*x-A2D5G8KbNfQiTlXo#r%v(y0B3E6I9LcOgRjVmYp!t&w)z1C4G7JaMePhSkWnZr$u*x+A2D5H8KcNfQiUlXo#s%v)y0B3F6I9LdOgRjVmYq!t&w-z1C4G7JbMePhTkWnZr$u(x+A2E5H8KcNfRiUlXp#s%v)y0C3F6IaLdOgSjVnYq!t*w-z1D4G8JbMeQhTkWoZr$u(x+B2E5H9KcNfRiUmXp#s&v)y0C3F7IaLdPgSjVnYq$t*w-A1D4G8JbNeQhTlWoZr%u(y+B2E6H9KcOfRjUmXp!s&v)z0C3F7IaMdPgSkVnYq$t*x- A1D5G8JbNeQiTlWo#r%u(y+B3E6H9LcOfRjUmYp!s&w)z0C4F7JaMdPhSkVnZq$u*x-A2D5G8KbNfQiTlXo#r%v(y+B3E6I9LcOgRjUmYp!t&w)z1C4F7JaMePhSkWnZq$u*x+A2D5H8KbNfQiUlXo#s%v(y0B3F6I9LdOgRjVmYq!t&w-z1C4G7JaMePhTkWnZr$u*x+A2E5H8KcNfQiUlXp#s%v)y0B3F6IaLdOgSjVmYq!t*w-z1D4G7JbMeQhTkWoZr$u(x+B2E5H9KcNfRiUlXp#s&v)y0C3F6IaLdPgSjVnYq!t*w-A1D4G8JbMeQhTlWoZr%u(x+B2E6H9KcOfRiUmXp!s&v)z0C3F7IaMTkWoZr$u(x+A2E5H9KcNfRiUlXp#s&v)y0C3F6IaLdPgSjVnYq!t*w- A1D4G8JbMeQhTlWoZr%u(x+B2E6H9KcOfRiUmXp!s&v)z0C3F7IaLdPgSkVnYq$t*w-A1D5G8JbNeQhTlWo#r%u(y+B2E6H9LcOfRjUmXp!s&w)z0C4F7IaMdPhSkVnZq$t*x-A2D5G8KbNeQiTlXo#r%v(y+B3E6H9LcOgRjUmYp!s&w)z1C4F7JaMdPhSkWnZq$u*x-A2D5H8KbNfQiTlXo#s%v(y0B3E6I9LdOgRjVmYp!t&w-z1C4G7JaMePhSkWnZr$u*x+A2D5H8KcNfQiUlXo#s%v)y0B3F6I9LdOgSjVmYq!t&w-z1D4G7JbMePhTkWoZr$u(x+A2E5H9KcNfRiUlXp#s%v)y0C3F6IaLdOgSjVnYq!t*w- z1D4G8JbMeQhTkWoZr%u(x+B2E5H9KcOfRiUmXp#s&v)z0C3F7IaLdPgSkVnYq$t*w-A1D5G8JbNeQhTlWoZr%u(y+B2E6H9KcOfRjUmXp!s&v)z0C4F7IaMhTkWoZr%u(x+B2E5H9KcOfRiUmXp#s&v)z0C3F7IaLdPgSjVnYq$t*w-A1D4G8JbNeQhTlWoZr%u(y+B2E6H9KcOfRjUmXp!s&v)z0C4F7IaMdPgSkVnZq$t*x-A1D5G8KbNeQiTlWo#r%v(y+B3E6H9LcOfRjUmYp!s&w)z0C4F7JaMdPhSkVnZq$u*x-A2D5G8KbNfQiTlXo#r%v(y0B3E6I9LcOgRjVmYp!t&w)z1C4G7JaMePhSkWnZq$u*x+A2D5H8KbNfQiUlXo#s%v(y0B3F6I9LdOgRjVmYq!t&w- z1C4G7JbMePhTkWnZr$u(x+A2E5H8KcNfRiUlXp#s%v)y0C3F6IaLdOgSjVmYq!t*w-z1D4G7JbMeQhTkWoZr$u(x+B2E5H9KcNfRiUmXp#s&v)y0C3F7IaLdPgSjVnYq$t*w-A1D4G8JbNeQhTlWoZr%u(x+B2E6H9KcOfRiUmXp!s&v)z0C3F7IaMdPgSkVnYq$+B2E5H9KcNfRiUmXp#s&v)y0C3F7IaLdPgSjVnYq!t*w-A1D4G8JbMeQhTlWoZr%u(x+B2E6H9KcOfRiUmXp!s&v)z0C3F7IaMdPgSkVnYq$t*x-A1D5G8JbNeQiTlWo#r%u(y+B3E6H9LcOfRjUmXp!s&w)z0C4F7IaMdPhSkVnZq$t*x- A2D5G8KbNeQiTlXo#r%v(y+B3E6I9LcOgRjUmYp!t&w)z1C4F7JaMePhSkWnZq$u*x-A2D5H8KbNfQiTlXo#s%v(y0B3E6I9LdOgRjVmYp!t&w-z1C4G7JaMePhTkWnZr$u*x+A2E5H8KcNfQiUlXp#s%v)y0B3F6IaLdOgSjVmYq!t&w-z1D4G7JbMePhTkWoZr$u(x+A2E5H9KcNfRiUlXp#s&v)y0C3F6IaLdPgSjVnYq!t*w-A1D4G8JbMeQhTlWoZr%u(x+B2E5H9KcOfRiUmXp#s&v)z0C3F7IaLdPgSkVnYq$t*w-A1D5KcNfRiUlXp#s&v)y0C3F6IaLdPgSjVnYq!t*w-z1D4G8JbMeQhTkWoZr%u(x+B2E5H9KcOfRiUmXp#s&v)z0C3F7IaLdPgSkVnYq$t*w- A1D5G8JbNeQhTlWo#r%u(y+B2E6H9LcOfRjUmXp!s&v)z0C4F7IaMdPgSkVnZq$t*x-A1D5G8KbNeQiTlWo#r%v(y+B3E6H9LcOgRjUmYp!s&w)z1C4F7JaMdPhSkWnZq$u*x-A2D5G8KbNfQiTlXo#r%v(y0B3E6I9LcOgRjVmYp!t&w)z1C4G7JaMePhSkWnZr$u*x+A2D5H8KcNfQiUlXo#s%v)y0B3F6I9LdOgSjVmYq!t&w-z1C4G7JbMePhTkWnZr$u(x+A2E5H8KcNfRiUlXp#s%v)y