軟件工程作業
1.什麽是RUP ?
RUP（Rational Unified Process），統一軟件開發過程，統一軟件過程)是一個面向對象且基於網絡的程序開發方法論。 瑞理統一過程（RUP）是Rational軟件公司（Rational公司被IBM並購）創造的軟件工程方法[1] 。RUP描述了如何有效地利用商業的可靠的方法開發和部署軟件，是一種重量級過程（也被稱作厚方法學），因此特別適用於大型軟件團隊開發大型項目。最佳實踐 六大經驗
1.叠代開發： RUP的開發過程建立在一系列叠代之上，每次叠代都有一個固定的時間限制（例如四個星期），稱為"時間盒"，每次叠代結束的時候都發布一個穩定的小版本，該版本是最終系統的子集。"時間盒"是叠代開發中的關鍵概念：它意味著叠代周期的期限是固定的，如果目標沒有完成，則放棄本次叠代的需求，而不是延長叠代的時間。
2.什麽xp?
極限編程（ExtremeProgramming，簡稱XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與WardCunningham共事時，就一直共同探索著新的軟件開發方法，希望能使軟件開發更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟件開發的前提條件、可能性以及面臨的困難。1996年三月，Kent終於在為DaimlerChrysler所做的一個項目中引入了新的軟件開發觀念——XP。適用於小團隊開發。
極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。XP是一種近螺旋式的開發方法，它將復雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。
極限編程的有效實踐
1、完整團隊 XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。 2、計劃遊戲 計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。 3、客戶測試 作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。 4、簡單設計 團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，並且包含盡可能少的代碼。 5、結對編程 所有的產品軟件都是由兩個程序員、並排坐在一起在同一臺機器上構建的。 6、測試驅動開發 編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然後使之通過。 7、改進設計 隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的幹凈、具有表達力。 8、持續集成 團隊總是使系統完整地被集成。一個人拆入（Check in）後，其它所有人責任代碼集成。 9、集體代碼所有權 任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發。 10、編碼標準 系統中所有的代碼看起來就好像是被單獨一人編寫的。 11、隱喻 將整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那麽你就知道該模塊是錯誤的。 12、可持續的速度 團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。3.什麽是敏捷過程？
敏捷開發以用戶的需求進化為核心，采用叠代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。
開發宣言
個體和交互 勝過 過程和工具 可以工作的軟件 勝過 面面俱到的文檔 客戶合作 勝過 合同談判 響應變化 勝過 遵循計劃 雖然右項也有價值，但是我們認為左項具有更大的價值敏捷開發的原則
1. 快速叠代 相對那種半年一次的大版本發布來說，小版本的需求、開發和測試更加簡單快速。一些公司，一年發布僅2~3個版本，發布流程緩慢，它們仍采用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。 2. 讓測試人員和開發者參與需求討論 需求討論以研討組的形式展開最有效率。研討組，需要包括測試人員和開發者，這樣可以更加輕松定義可測試的需求，將需求分組並確定優先級。 同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。 3. 編寫可測試的需求文檔 開始就要用“用戶故事”（User Story）的方法來編寫需求文檔。這種方法，可以讓我們將註意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的註意力。 4. 多溝通，盡量減少文檔 任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裏面混得越久，越會強調良好高效的溝通的重要性。 團隊要確保日常的交流，面對面溝通比郵件強得多。 5. 做好產品原型 建議使用草圖和模型來闡明用戶界面。並不是所有人都可以理解一份復雜的文檔，但人人都會看圖。 6. 及早考慮測試 及早地考慮測試在敏捷開發中很重要。傳統的軟件開發，測試用例很晚才開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了
軟件工程作業