軟件開發(fā)模式

軟件開發(fā)模式龍廣宇、夏小游 如何打造一個夢想中心？ 你所熟悉的過程一、定位？時間？資源？目標？出個TOR吧！=可行性研究與計劃二、老師要什么？學生要什么？捐贈人要什么？出個需求調研報告吧！=需求分析三、是PAD還是電腦？涂料選啥顏色？要不要加個3D打印機？出個設計稿吧！=設計四、貨到了，要找個當地的師傅刷墻、布線、鋪地板，出個建設指南吧！=開發(fā) 五、書都擺上書架嗎？PAD有裝錯嗎？出個竣工報告吧！=測試六、喂，真愛夢想嗎？夢想中心電腦壞了，能幫忙重裝下系統(tǒng)嗎？成立個VOT吧！=運維 瀑布模型瀑布模型是典型的傳統(tǒng)軟件開發(fā)模型之一特點：自上而下，固定次序，逐級下落優(yōu)點： 開發(fā)的各個階段比較清晰 強調早期計劃及需求調查 適合需求穩(wěn)定的產品開發(fā)缺點： 依賴于早期需求調查，不適應需求的變化 在項目各個階段之間極少有反饋。 風險往往遲至后期才顯露，失去盡早糾正的機會 瀑布模型 第一帕、傳統(tǒng)軟件開發(fā)模式 開發(fā)模型 邊做邊改模型（Build-and-Fix Model） 瀑布模型（Waterfall Model） 快速原型模型（Rapid Prototype Model） 增量模型（Incremental Model） 螺旋模型（Spiral Model） 演化模型(evolution model) 噴泉模型(fountain model)更多 螺旋模型 UML（統(tǒng)一建模語言）作用：用于對軟件密集型系統(tǒng)的制品進行可視化、詳述、構造和文檔化的圖形語言。特點： UML規(guī)范用來描述建模的概念有，類（對象的）、對象、關聯、職責、行為、接口、用例、包、順序、協(xié)作，以及狀態(tài)。 UML從考慮系統(tǒng)的不同角度出發(fā)，定義了10類圖：用例圖、類圖、對象圖、包圖、狀態(tài)圖、時序圖/順序圖、合作圖、活動圖、構件圖、配置圖。 建模概念 用例圖 類圖活動圖 狀態(tài)圖序列圖 V-MODLE 單元測試：按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被正確的編譯。 集成測試：將各單元組合成完整的體系，主要測試各模塊間組合后的功能實現情況，以及模塊接口連接的成功與否，數據傳遞的正確性等。 系統(tǒng)測試：把軟件系統(tǒng)搭建起來，按照軟件規(guī)格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運行是否存在漏洞等。 驗收測試：用戶驗收時根據需求、規(guī)格說明書來做相應測試，以確定軟件達到符合效果的。 V-modle WBS/PBSPBS（產品分解結構）：通過樹狀結構反映產品的各類部件，每類部件在結構中僅出現一次。WBS（工作分解結構）：對應當由項目團隊執(zhí)行以便實現項目目標，并創(chuàng)造必要的可交付成果工作，按可交付成果所做的層次分解。 PBS WBS 甘特圖作用：可以直觀地表明任務計劃在什么時候進行，及實際進展與計劃要求的對比。 橫軸表示時間 縱軸表示活動（項目） 線條表示在整個期間上計劃和實際的活動完成情況含義： 以圖形或表格的形式顯示活動。 現在是一種通用的顯示進度的方法。 構造時應包括實際日歷天和持續(xù)時間，并且不要將周末和節(jié)假日算在進度之內。 甘特圖 軟件變更管理主要任務：1、分析變更的必要性和合理性，確定是否實施變更。2、記錄變更信息，填寫變更控制單。3.、做出更改，并提交審批。 4、修改相應的軟件配置項（基線），確立新的版本。 5、評審后發(fā)布新版本。 變更表 Q：傳統(tǒng)軟件開發(fā)模式有何優(yōu)劣勢？ Guangyu Long總結“傳統(tǒng)軟件開發(fā)特點是交付階段明確定義、每環(huán)節(jié)要求交付件與評審；質量控制嚴謹；項目周期長；不易管理變更?！?第二帕、敏捷軟件開發(fā)模式 用戶故事第一步、解釋故事。1. 用戶投入一些錢。2. 售貨機顯示用戶已經投了多少錢。3. 如果投入的錢足夠買某種飲料，這種飲料對應的按鈕的燈就會亮。 4. 用戶按了某個亮了的按鈕。5. 售貨機賣出一罐飲料給他。6. 售貨機找零錢給他。第二步、評估開發(fā)時間-故事點賣飲料 4取消購買 2輸入管理密碼 1 補充飲料 3取出錢箱里的錢 1安全警報 2打印月銷售報表 4總計 17 客戶需求：“用戶往售貨機每塞一個硬幣，售貨機都要顯示當前該客戶已經投了多少錢。當用戶投的錢夠買某一款飲料時，代表這款飲料的按鈕的燈就會亮。如果那個用戶按了這個按鈕，售貨機就放一罐飲料到出口，然后找零錢給他。” Q：假設一個故事點5人日，有2個開發(fā)人員，請預估開發(fā)時長？Q：一個迭代（2周10個工作日）之后，完成了2.5個故事點，請重新預估開發(fā)時長？Q：故事點與傳統(tǒng)工作量的預估方式有何區(qū)別？用戶故事 極限編程（XP）極限編程（XP）：一種針對業(yè)務和軟件開發(fā)的方法，其作用在于將兩者的力量集中在共同的、可以達到的目標上，使XP團隊以可持續(xù)的步調生產優(yōu)質的軟件。基于敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐。1. 團隊協(xié)作(Whole Team)2. 規(guī)劃策略(The Planning Game)； 3. 結對編程(Pair programming)4. 測試驅動開發(fā)(Testing-Driven Development)5. 重構(Refactoring)6. 簡單設計(Simple Design)7. 代碼集體所有權(Collective Code Ownership) 8. 持續(xù)集成(Continuous Integration)9. 客戶測試(Customer Tests)10. 小型發(fā)布（Small Release）11. 每周40小時工作制（40-hour Week）12. 編碼規(guī)范（Code Standards） 13. 系統(tǒng)隱喻（System Metaphor） 價值與風險驅動小項目、小團隊的開發(fā)管理比較純粹在人員比較多、項目比較復雜的情況下，價值與風險的因素需要有個治理的守候框架 Q：敏捷軟件開發(fā)模式有何優(yōu)劣勢？ 總結個體和交互 重于 過程和工具可以工作的軟件 重于 求全責備的文檔客戶協(xié)作 重于 合同談判相應變化 重于 循規(guī)蹈矩 第三帕、互聯網開發(fā)模式 特點業(yè)務敏捷性開發(fā)敏捷性開發(fā)測試云自動化 DevOps (軟件持續(xù)交付)