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