1、軟件工程 第三組 張清健 陳敏軍 陳明艷 李桂萍 沙爾合提 11.171.解釋為什么對新系統來說 快速交付和部署要比這些系統的具體功能重要？ 時效性 可靠性 風險性2.解釋敏捷方法的基本原理是如何能帶來加速的軟件開發和部署？ 敏捷的各種實踐中，能夠加速軟件開發的因素有很多，比如：1、加快對客戶需求變化的響應2、減少產出不必要的工件3、強化溝通，降低因溝通導致的損耗4、建立自組織的團隊，激勵團隊人員5、使開發人員專心從事當前事務 敏捷聯盟宣言: 個體和交互高于過程和工具; 可以工作的軟件高于詳盡的文檔;(甲骨文公司) 客戶合作高于合同談判; 響應變化高于遵循計劃;3.什么情況下勸告不用敏捷開發來

2、開發工程? 敏捷開發宣言里各種許愿拔掉敏捷二字不也是所有項目開發的理想？所以為了解決什么問題而采用敏捷式開發？為了改善工作流程加快效率?那設計師修改到死的工作情況在敏捷開發里要怎么被改善? 我覺得敏捷開發適用頭腦清楚的人，只是這種人往往是大神級的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、別人在干嘛，還能 Cover 一點別人的領域，知道解決這個問題可以往目標更進一步，這種合作模式才有辦法做到敏捷，而不是因為抓漏抓蟲在修改。是啦這也算朝目標邁進，但創新改 良產品和讓產品看起來洞沒那么大的改來改去本質上是兩回事啊！敏捷開發只是個方法，不是萬靈丹。4.極限編程是

3、用故事情節來表達用戶需求的,每一個情節寫在卡片上,討論這種描述方法的優點和缺點？ 我覺得XP是一個輕量級的、靈巧的軟件開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇于實事求是。XP是一種近螺旋式的開發方法，它將復雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，并根據實際情況及時地調整開發過程。 因此,它的優點有以下幾點:1. 對公司的開發者而言，XP可以讓開發者

4、專注于編寫 代碼，避免了不必要的文案工作及會議。它營造了更好的工作氛圍，更多學習新技術的機會，并令你的員工有成就感。 2. 相比于傳統開發方式，通過XP開發的軟件缺陷更少。 它令公司對其商業需求的變化做出更快速的反應，而且價格低廉，開發者也少有怨言。 從公司管理的角度來看，這種方法可以減少你對牛人 的依賴。同時它也提升了員工滿意度。 在XP下，你無需設計未來。你設計今天。整個理念 就是，寫簡單代碼，以及在需求改變的時候相應的改變你的設計。你的開發人員是兩人結隊編程，從頭到尾都在一起 工作。代碼有著統一的規范性和可讀性，大家都能夠理解代碼并按照需求改善代碼。而且，結隊編程在一定時間內是最有效率的

5、。 XP項目與傳統軟件開發的最大區別在于，XP是以測 試推動開發。在XP下可以在編寫代碼之前開始測試。每一個環節的代碼都要100%通過單元測試。沒有unit-level bug和回歸bug也意味著開發者能夠專注他們自己的工作。你的客戶確立自動驗收測試以確認該軟件的每一個功能的運行質量。 在XP下，每一個測試階段之后都可以發布一個小體 積軟件。最重要的是，每一階段完成時都有些東西能夠拿給客戶看。 在傳統流水線方式下，如果項目計劃變更，之后要趕 上檔期就會需要很大投入。XP的方法可以令你提前判斷進程。 極限編程從最簡單的解決方案入手。你可以在之后添 加其他功能。這個概念的目的在于為今天做計劃，設計

6、及編碼，而不是為了明天。 來自系統，客戶和團隊的反饋是極限編程成功的 關鍵。在這個概念的指導下，系統的漏洞在前期就被發現，客戶可以反復進行驗收測試，從而最大限度的極限編程而它的缺點在于:以代碼為 中心，忽略了設計；缺乏設計文檔，局限于小規模項目；對已完成工作的檢查步驟缺乏清晰的結構；質量保證依賴于測試；缺乏質量規劃；沒有提供數據的收集和使用的指導；開發過程不詳細；全新的管理手法帶來的認同度問題；缺乏過渡時的必要支持。5. 解釋為什么測試優先的開發能幫助程序猿獲得對系統需求的更好的理解 不同于先寫代碼，然后對這些代碼寫相應的測試程序，XP是先寫測試程序，再寫代碼的。這就意味著，再寫程序的同時你可

7、以運行測試代碼。先寫測試隱含地定義了界面和要開發的功能的行為描述。減少了對需求和界面的誤解。對于任何在系統需求和實現該需求的代碼之間有明確關系的過程中都可以采用此方法。測試優先開發中，實現任務的人必須徹底理解描述，這樣他們才能為系統編寫測試。這意味著在描述中的二義性和遺漏必須在實現開始之前得以澄清。程序員在這個過程中對系統需求理解會更加深刻。 困難：測試優先的開發和自動測試通常導致要編寫和執行大量的測試程序。然而，這種方法并不一定使程序得到徹底的測試。原因有下：1、程序員更喜歡編程而不是測試，有時候在測試時走捷徑。例如，寫出不完整的測試無法檢測所有可能的異常情況。2、有一些測試是非常困難的。例

8、如。在復雜用戶界面中，通常編寫用于實現“顯示邏輯”和屏幕間工作流的測試單元是十分困難的。3、對一組測試的完整性的判斷也是困難的。盡管你可以有很多系統測試，你的測試集合可能不能提供完整的覆蓋。系統的關鍵部分可能得不到執行，所以也就是沒有經過測試的。6.給出4個理由說明為什么結對編程的軟件生產率比程序猿單個編程時高 1、它可以促進參與項目的程序員自身的提高，一對程序員工作的時候，水平較低的一方會潛移默化地受水平略高的程序員影響，學到一些新的東西。而水平高的一方同樣因為不斷地把自己的想法說出來而整理了自己的思路。 2.一定時間周期地打亂配對，讓參與項目的人員相互轉換位置，使得維護繁雜的文檔變得不那么

9、重要。大家分組打亂后，口頭的交流很容易讓所有人都熟悉每個模塊，這樣對于公司也很有好處，項目中萬一有人離開，也不至于影響到整個項目。最后，開發過程變得更為有趣，任何人的交流變得很多，大家關系更為融洽。 3.結對編程有一種相互督促的作用，在一邊工作疲憊狀態不好使，另一邊會起一個鼓勵和激發斗志的作用。 4.有助于支持重構，這是一個軟件改善的過程。7.比較scrum和第23章介紹的常規的計劃驅動的項目管理方法.Scrum 方法是一個通用的敏捷方法,注重迭代開發的管理,有3個階段:1規劃綱要 2沖刺循環 3項目結束Scrum 中心階段沖刺循環過程的要點: 1有固定長度 2起點積壓的任務(用戶緊密參與,提

10、出新需求或任務的建議) 3項目團隊所有人員與用戶一起選擇要開發的特性和功能 4團隊組織軟件開發 5對已做工作復查并交付給用戶。優點：使開發團隊不受外界干擾，工作方式取決于遇到的問題和團隊，對如何寫需求，測試優先開發等不作具體要求。其中，1.產品被分解成一組可管理和可被解決的塊 2.不穩定的需求并不阻礙工程進展 3.整個團隊的所有事情可見，改善了團隊的溝通 4.用戶看到增量的及時交付，且得到對產品如何工作的反饋 5.客戶和開發者之間彼此信任，創造了積極文化和項目成功的希望。常規的計劃驅動的項目管理方法：初始階段-基于用戶情節，應包含在系統中。在項目啟動前，開發團隊與用戶試著定義一系列情節。評估階

11、段-項目組閱讀并討論這些情節，按所需時間將情景排序并“速度”估計。 發布規劃選擇完善情景。 迭代規劃開發人員將情景拆分各個開發任務進行詳細規劃。優點：整個項目組對迭代過程要完成的任務有整體認識；開發者自行選擇任務，激發積極性更好的完成任務。缺點：依賴于客戶參與；對于龐大且分布在不同地點的項目組或組員頻繁變動的項目組而言，不可能每個人參與到項目最核心的集體規劃中。8.系統是要支持將軟件需求翻譯成形式化軟件描述，評論下列開發策略的優點和缺點 策略a：優點：使開發團隊不受外界干擾，工作方式取決于遇到的問題和團隊； 缺點;需求范圍面不足，導致設計的軟件適用性弱；對于龐大系統，很難做到解決問題全面，只適

12、用于小型系統。 策略b：優點：評估項目做到盡可能全面，使系統更完善。 缺點：采用java開發系統，導致其他語言或軟件不適用，大大縮減了應用范圍。 策略c：優點：增強和改善了團隊的溝通，建立了客戶與開發者間的信任；采用敏捷開發系統，不受外界干擾，大大提高了創新能力。 缺點：受項目組員的技術及人員變動的影響較大，很難突破創新，在大型公司中很難引入，可能在文化上受到抵制。9.對于團隊成員采納開發團隊的觀點而忽視用戶隊員的需求，寫出三個建議 計劃驅動開發：迭代發生在各個活動之中，用正式文件在軟件過程的各個階段之間進行溝通，例如 需求將演化。然而我們需要考慮詳細的描述和設計是否很重要，用戶反饋是否切實，

13、預想的系統壽命是多少？ 極限編程：客戶親密地投入到系統需求的定義和優先權排序工作中，但是它使軟件結構有變壞的趨勢，變得越來越難實現，代碼經常重復。 結對編程：支持共同擁有軟件的和共同對系統負責，擔當了非正式的復查過程有助于支持重構，缺點是編程效率低，容易出錯。10.為了降低成本和交通環境的影響。請寫出你將如何應對這些問題 大型公司通常有質量保證流程和標準，當團隊成員技術都比較高時，敏捷方法似乎能工作得更好，然而在大型機構中員工的技術和能力很可能是層次不齊的，那些水平較低的員工可能成為無效的員工。此外員工可能從文化上抵制敏捷開發。 解決方法：引進和維持敏捷在大型機構中的使用是一個文化改變的過程，

14、文化改變需要一段很長的時間去實現，而且通常需要先改變管理方式才能實現，大型機構中希望應用敏捷需要傳道者去推動改變，他們必須投入很多資源去改變流程。11.對于什么類型的系統敏捷開發方法特別有可能成功？ 小型和中型軟件產品開發。 定制軟件開發組織中,有一個客戶參與開發過程的明確承諾。12.列出敏捷方法的5個原則？ 客戶參與； 增量式交付； 人非過程； 接受變更； 維護簡單。友情提醒：P3713.列表4個在決定是否采用敏捷的軟件開發方法時應該考慮的的問題？ 是一個增量交付可以現實的嗎？什么類型的系統正在開發？預期的系統生命周期是什么？開發團隊是如何組織的？系統是否受到外部監管？正在開發的系統有多大規模？14.極限編程的三個重要的特點是什么? 需求表示為腳本；P40 結對編程； 測試優先的開發。15.測試優先的開發是什么? 當系統功能是被認同的,測試的代碼實現的功能是在代碼之前編寫的。測試是自動的并且新的增量添加到系統中時運行所有的測試。16.測試優先的開發的可能出現的問題是什么? 程序員可能在開發測試中采取捷徑,系統測試是不