4-2数位家庭软体开发与再利用.pptVIP

1.難去發現問題因為沒文件，因為沒文件當如果有人離職後可能會造成接續的人無法了解 2.因為會一值增減需求，所以對於經費功能有可能對於起始的合約不同 3.沒規格書，所以在測試方面無法做其完整測試 4.一值在改變會使結構一值改變，有可能會因此產生其他的問題，會使維護者維護上有問題 敏捷的方法rely on iterative因為要一值增加需求，在此方法上 E.G.像教學網站 1.用戶需長時間與開發的人接觸，以提供最適合的需求 2.每當增加時，文件規格一定要附加 3.把一些技巧要給留下，而不要使人成為開程式重要的步驟(也就是快速發展文件不夠齊全產生的後果) 4.因為需求會增加，設計時要預留一些空間 5.維護上以簡單為基本 1.很難一值要求客戶與你參與 2.不可以有個人特質，以免後續者不好使用(要能願意接受他人撰寫ㄉ程式，不要以為只有自己ㄉ才是好ㄉ) 3.因為是依照逐次增加，那會有誰先需要修改的問題，例如教學網站:上傳作業OR成績公佈 XP 亦稱為終極流程，是最輕量級的開發流程，其最主要的精神是『在客戶有系統需求時，給予及時滿意的可執行程式』， 1.New versions may be built several times per day; 2.Increments are delivered to customers every 2 weeks; 3.All tests must be run for every build and the build is only accepted if tests run successfully. 由STORY CARD紀錄所需求 2.需求存在故事卡裡，當需求要改變已改變此內容，始發展者知道如何修改 4.先設計最基本的要求，e.g網站流言版ㄉ功能可以晚一點設計、萬年曆(教學網站就是這樣) 4.簡單的設計e.g不用flash…..等 9.要使程式能再分解使用，故會始其程式簡單且易維護(就是不更改程式功能，而改變程式的結構，和程式變得更好 ) 5.先行測試，在實作前先測試(先做出一個測試的環境) 7.8.一起做全局的開發而非和傳統軟工分區塊進行，選擇部分優秀者之程式做為使用 1.不可以有over time 3.客戶也是需要一值參與 結對編程(Pair?Programming)。既然對設計、對代碼的評審是好的，那麼為什麼不隨時評審呢？通過評審，我們可以用多個人的腦袋想問題，尋找解決方案，無疑這要比只用一個腦袋要好的多，畢竟人多力量大嘛，曾經也有教育家做過試驗，證明了在群組討論學習的環境下學生學到的知識更深刻，理解的更透徹，思想也更活躍。軟件開發又何嘗不是如此呢？我不完全贊成「結對」，但是我贊成有問題就問，不管什麼樣的問題，不管什麼樣的同事，只要你有疑問，那麼你就可以向大家提出來，看看每個人的想法，這會使你最終得到一個當前最好的解決方案。 集體所有權(Collective Ownership)。在上個實踐中其實已經提到了這個集體所有權的概念，既然你有問題就可以問，別人又都參與你給你他們認為的可能性答案，那麼是不是反過來但別人有問題的時候你也要主動參與提出自己的看法呢？這種把多個大腦運作在一起的模式就是XP中集體所有權的概念了，在這裡沒有個人的殊榮，只有團體與團體的共同目標。注意這裡就是XP的特點了，XP是以人為本，XP堅信人與人之間的作用要比單純的依靠技術要更重要的多。畢竟只有最後依靠到人心上，項目才可能獲得最後的成功。而作為一名XP開發人員也意味著你的個人休養與風格。 持續集成(Continuous Integration)。這是另一種保證質量的測試手段，通過反覆快速的集成我們可以及早發現軟件中的隱患，同時持續集成也可以提供給我們多個小版本(Small Releases)以便客戶的反饋。這個概念比較像微軟提出的每日編譯，只是XP並沒有規定必須每日執行一次，XP反而主張每幾個小時甚至每幾分鐘集成一次，總之就是當有較大變動時就及時集成給出反饋，這一點也能夠充分的體現出XP極限編程中的極限來！ 把所需的寫下，發展者可以依照此去實作與估價 In XP, programmers work in pairs, sitting together to develop code. 1.用team對於程式與知識的交流較有幫助，而非以個人的觀點 2.多人可以一起看錯誤 3.一起重整可以獲取較大利益(它的觀點) Measurements suggest that development productivity with pair programming is similar to that of two people working independently可避免工作重複 A pro