上课第三章.ppt

並列爭球的軟體流程模式與活動 展示(Demos) 運送軟體漸進版本給客戶，使得實作的功能性可以對向客戶展示並評估。 展示可能不包含計劃中的所有功能性，但寧可將那些可於時間盒內可建立的功能交付。 並列爭球的流程 4.3.5 水晶(Crystal) Alistair Cockburn和Jim Highsmith創造機敏方法的結晶家族(Crystal family of agile methods)以達成軟體發展方式 將premium在「可操作性(maneuverability)」在期間Cockburn特性化成為「有限資源、發明與溝通的合作遊戲，以最主要的目標 交付有用、可工作的軟體和建立在下一個遊戲的第二目標」。 要達成可操作性，Cockburn和Highsmith定義一套方法學，對全體每個都有核心元件和角色、流程、模式、工作產品和實務對每個都是獨有的。 結晶家族實際上是一套經證明對不同類型的專案是有效的機敏流程。其意圖讓機敏團隊選擇對他們的專案與環境最適合的結晶家屬成員。 4.3.6 性能驅動發展(Feature Driven Development, FDD) 性能驅動發展(FDD)緣於Peter Coad和他同事的構思，作為物件導向軟體工程的實務流程模型。 Stephen Palmer和John Felsing 則擴展與強化Coad的工作，描述出適應性的機敏流程，以應用到中型和較大型的軟體專案中。 FDD環境中的性能 在FDD的環境中，性能(feature)「是可於二週或更短的時間內實作，達成客戶價值(client-valued)的功能」。 這種對於特性定義上的強調提供了以下的好處： 因為特性都是可遞送功能性的一些小區塊，使用者可以更容易地描述它們，瞭解它們如何與彼此保持良好關係，和對不明確、錯誤或疏忽的地方進行更好的檢視。 特性可以組織到階層式商務相關的群組內。 FDD環境中的性能 因為一個特性是FDD可交付的軟體漸進版本，團隊每二週發展出可運作的特性。 因為特性很小，它們設計和編碼的呈現更容易有效地檢查。 專案的計劃、排程和追蹤是由性能階層(feature hierarchy)所驅動，而不是任意地採用地軟體工程任務組(task set)。 定義性能的樣版 Coad和他的同事建議使用以下的樣版(templete)定義性能： action the result by I for I of I to a(n) object 其中object是「一個人、地方或事物(包括角色、時刻或時間的間隔或類似目錄輸入般(catalog-entry-like)的描述」。 性能範例 一個電子商務應用程式的性能範例如下： 加入(Add)產品(product)到(to)購物車(a shopping cart)。 顯示(Display)產品(product)的技術規格(technical-specifications)。 儲存(Store)運送資料(shipping-information)為(for)客戶(a customer)。 性能集合群組 相關到商務相關領域性能的一個性能集合群組被定義成為： action-ing a(n) object 舉例說明：產品銷售(making a product sale)是一個性能集合，它將含括上述與其他的性能。 FDD定義的「流程」 FDD方式定義五種「協調合作」框架活動(在FDD中稱這些為「流程」)，如圖4.4所示。 FDD比許多其他的機敏方法，更為強調專案管理指導方針與技術。 當專案的規模更大更複雜時，隨意的(ad hoc)專案管理經常是不充足的。這是開發者、他們的經理和客戶想要瞭解計畫狀態的基礎– 那些已經完成和所遇到的問題等。 如果截止日期的壓力非常重，則軟體漸進版本(特性)已適當地排程，就是一項重要的決定。 圖4.4 性能驅動發展 FDD定義的里程碑 在設計與實作特性時，FDD定義六項里程碑(milestons)： 設計攻略(design walkthrough) 設計 設計檢查(design inspection) 編碼 編碼檢查(code inspection) 促進建構(promote to build)」 4.3.7 機敏塑模(Agile Modeling, AM) 軟體工程師在很多情況下一定要建立大的、有重大的商務系統。這類範圍和複雜度的系統必須塑模，以便: 所有的成件(constituencies)能更為瞭解所需要完成的事件； 在必須解決問題的人們之間有效地切割問題； 當系統被工程化與建造時，品質能在每個步驟中評估。 機敏塑模(AM) 在「官方的機敏塑模網站」中，Scott Ambler[AMB02]以下述的方式描述機敏塑模(AM)： 機敏塑模(AM)是