1、軟件開發(fā)模式,龍廣宇、夏小游,如何打造一個(gè)夢(mèng)想中心？,你所熟悉的過程,一、定位？時(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è)指南吧！=開發(fā) 五、書都擺上書架嗎？PAD有裝錯(cuò)嗎？出個(gè)竣工報(bào)告吧！=測(cè)試 六、喂，真愛夢(mèng)想嗎？夢(mèng)想中心電腦壞了，能幫忙重裝下系統(tǒng)嗎？成立個(gè)VOT吧！=運(yùn)維,瀑布模型,瀑布模型是典型的傳統(tǒng)軟件開發(fā)模型之一 特點(diǎn)：自上而下，固定次序，逐級(jí)下落 優(yōu)點(diǎn)： 開發(fā)的各

2、個(gè)階段比較清晰 強(qiáng)調(diào)早期計(jì)劃及需求調(diào)查 適合需求穩(wěn)定的產(chǎn)品開發(fā) 缺點(diǎn)： 依賴于早期需求調(diào)查，不適應(yīng)需求的變化 在項(xiàng)目各個(gè)階段之間極少有反饋。 風(fēng)險(xiǎn)往往遲至后期才顯露，失去盡早糾正的機(jī)會(huì),瀑布模型,第一帕、傳統(tǒng)軟件開發(fā)模式,開發(fā)模型,邊做邊改模型（Build-and-Fix Model） 瀑布模型（Waterfall Model） 快速原型模型（Rapid Prototype Model） 增量模型（Incremental Model） 螺旋模型（Spiral Model） 演化模型(evolution model) 噴泉模型(fountain model) 更多,螺旋模型,UML（統(tǒng)一建模語言

3、）,作用：用于對(duì)軟件密集型系統(tǒng)的制品進(jìn)行可視化、詳述、構(gòu)造和文檔化的圖形語言。 特點(diǎn)： UML規(guī)范用來描述建模的概念有，類（對(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)情況，以及模塊接口連接的成功與

4、否，數(shù)據(jù)傳遞的正確性等。 系統(tǒng)測(cè)試：把軟件系統(tǒng)搭建起來，按照軟件規(guī)格說明書中所要求，測(cè)試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運(yùn)行是否存在漏洞等。 驗(yàn)收測(cè)試：用戶驗(yàn)收時(shí)根據(jù)需求、規(guī)格說明書來做相應(yīng)測(cè)試，以確定軟件達(dá)到符合效果的。,V-modle,WBS/PBS,PBS（產(chǎn)品分解結(jié)構(gòu)）：通過樹狀結(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)

5、（項(xiàng)目） 線條表示在整個(gè)期間上計(jì)劃和實(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、記錄變更信息，填寫變更控制單。 3.、做出更改，并提交審批。 4、修改相應(yīng)的軟件配置項(xiàng)（基線），確立新的版本。 5、評(píng)審后發(fā)布新版本。,變更表,Q：傳統(tǒng)軟件開發(fā)模式有何優(yōu)劣勢(shì)？,Guangyu Long,總結(jié) “傳統(tǒng)軟件開發(fā)特點(diǎn)是交付階段明確定義、每環(huán)節(jié)要求交付件與評(píng)審；質(zhì)量控制嚴(yán)謹(jǐn)；項(xiàng)目周期長(zhǎng)；不易管理變更。

6、”,第二帕、敏捷軟件開發(fā)模式,用戶故事,第一步、解釋故事。 1. 用戶投入一些錢。 2. 售貨機(jī)顯示用戶已經(jīng)投了多少錢。 3. 如果投入的錢足夠買某種飲料，這種飲料對(duì)應(yīng)的按鈕的燈就會(huì)亮。 4. 用戶按了某個(gè)亮了的按鈕。 5. 售貨機(jī)賣出一罐飲料給他。 6. 售貨機(jī)找零錢給他。 第二步、評(píng)估開發(fā)時(shí)間-故事點(diǎn) 賣飲料 4 取消購買 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ī)就

7、放一罐飲料到出口，然后找零錢給他?！?Q：假設(shè)一個(gè)故事點(diǎn)5人日，有2個(gè)開發(fā)人員，請(qǐng)預(yù)估開發(fā)時(shí)長(zhǎng)？Q：一個(gè)迭代（2周10個(gè)工作日）之后，完成了2.5個(gè)故事點(diǎn)，請(qǐng)重新預(yù)估開發(fā)時(shí)長(zhǎng)？Q：故事點(diǎn)與傳統(tǒng)工作量的預(yù)估方式有何區(qū)別？,用戶故事,極限編程（XP）,極限編程（XP）：一種針對(duì)業(yè)務(wù)和軟件開發(fā)的方法，其作用在于將兩者的力量集中在共同的、可以達(dá)到的目標(biāo)上，使XP團(tuán)隊(duì)以可持續(xù)的步調(diào)生產(chǎn)優(yōu)質(zhì)的軟件。 基于敏捷的核心思想和價(jià)值目標(biāo)，XP要求項(xiàng)目團(tuán)隊(duì)遵循13個(gè)核心實(shí)踐。,團(tuán)隊(duì)協(xié)作(Whole Team) 規(guī)劃策略(The Planning Game)； 結(jié)對(duì)編程(Pair programming) 測(cè)試驅(qū)動(dòng)開

8、發(fā)(Testing-Driven Development) 重構(gòu)(Refactoring) 簡(jiǎn)單設(shè)計(jì)(Simple Design) 代碼集體所有權(quán)(Collective Code Ownership) 持續(xù)集成(Continuous Integration) 客戶測(cè)試(Customer Tests) 小型發(fā)布（Small Release） 每周40小時(shí)工作制（40-hour Week） 編碼規(guī)范（Code Standards） 系統(tǒng)隱喻（System Metaphor）,價(jià)值與風(fēng)險(xiǎn)驅(qū)動(dòng),小項(xiàng)目、小團(tuán)隊(duì)的開發(fā)管理比較純粹 在人員比較多、項(xiàng)目比較復(fù)雜的情況下，價(jià)值與風(fēng)險(xiǎn)的因素需要有個(gè)治理的守候框架,Q：敏