《軟件工程》第2課軟件生存周期與軟件過程

1、第軟件生存周期與軟件過程知識(shí)回顧 軟件工程學(xué)的范疇過程、方法、工具 軟件工程的發(fā)展三種編程范式三代軟件工程前饋及作業(yè)總結(jié) 作業(yè)電子版、筆記都可以，電子版隨每次前饋一起提交，筆記定期檢查。 自學(xué)情況、需要精講要填選，必須提出問題，要每個(gè)人都有，提出1-2個(gè)好問題。 名稱：第X小組軟件工程課程前饋表，每個(gè)小組集成到一個(gè)文件中。用QQ發(fā)離線文件交給我。問題解答 如果我們自己研究一個(gè)項(xiàng)目，怎么確定使用哪個(gè)模型進(jìn)行研發(fā)，每個(gè)如果我們自己研究一個(gè)項(xiàng)目，怎么確定使用哪個(gè)模型進(jìn)行研發(fā)，每個(gè)模型各有特點(diǎn)，優(yōu)缺點(diǎn)，是否可以根據(jù)需求在軟件開發(fā)的階段選擇最模型各有特點(diǎn)，優(yōu)缺點(diǎn)，是否可以根據(jù)需求在軟件開發(fā)的階段選擇最合

2、適的模型進(jìn)行研發(fā)？馬振興合適的模型進(jìn)行研發(fā)？馬振興 在軟件風(fēng)險(xiǎn)中，有一項(xiàng)是編程人員離職，畢竟編程人員每個(gè)人的編碼在軟件風(fēng)險(xiǎn)中，有一項(xiàng)是編程人員離職，畢竟編程人員每個(gè)人的編碼風(fēng)格不同，怎么能降低這一情況產(chǎn)生時(shí)對(duì)項(xiàng)目的負(fù)面影響？史孟然風(fēng)格不同，怎么能降低這一情況產(chǎn)生時(shí)對(duì)項(xiàng)目的負(fù)面影響？史孟然 螺旋模型從表面上看是采用了之前各個(gè)模型的優(yōu)點(diǎn)建立的（保證了質(zhì)螺旋模型從表面上看是采用了之前各個(gè)模型的優(yōu)點(diǎn)建立的（保證了質(zhì)量），但是螺旋模型的每一個(gè)小部分都使用瀑布模型和原型豈不是增量），但是螺旋模型的每一個(gè)小部分都使用瀑布模型和原型豈不是增加了開發(fā)成本和時(shí)間？陳萬敏加了開發(fā)成本和時(shí)間？陳萬敏前饋檢查 把生存周

3、期劃分為階段的目的是什么？ 傳統(tǒng)的瀑布模型把生存周期分為哪些階段？ 可行性研究包含哪些內(nèi)容？ 為什么要進(jìn)行風(fēng)險(xiǎn)分析？講授內(nèi)容 生存周期與軟件過程的關(guān)系 傳統(tǒng)的軟件過程 瀑布模型、快速原型模型 軟件演化模型 增量模型、螺旋模型 、構(gòu)件集成模型 統(tǒng)一過程和敏捷過程 軟件可行性研究 可行性研究的內(nèi)容與步驟 軟件風(fēng)險(xiǎn)分析第二章 軟件生存周期與軟件過程p軟件生存周期軟件生存周期p傳統(tǒng)的軟件過程傳統(tǒng)的軟件過程p軟件演化模型軟件演化模型p統(tǒng)一過程和敏捷過程統(tǒng)一過程和敏捷過程p軟件可行性研究軟件可行性研究1. 軟件生存周期 軟件生存周期軟件生存周期（Software Life Cycle）：一個(gè)軟件項(xiàng)目從問）

4、：一個(gè)軟件項(xiàng)目從問題提出開始，直到軟件產(chǎn)品最終退役（廢棄不用）為止。題提出開始，直到軟件產(chǎn)品最終退役（廢棄不用）為止。 軟件生存周期分為三個(gè)時(shí)期：軟件生存周期分為三個(gè)時(shí)期：計(jì)劃、開發(fā)和維護(hù)計(jì)劃、開發(fā)和維護(hù) 整個(gè)軟件生存周期劃分為多個(gè)相對(duì)獨(dú)立的較小整個(gè)軟件生存周期劃分為多個(gè)相對(duì)獨(dú)立的較小階段階段，給每，給每個(gè)階段賦予確定而有限的任務(wù)，從而降低了整個(gè)軟件工程個(gè)階段賦予確定而有限的任務(wù)，從而降低了整個(gè)軟件工程的難度，提高了軟件開發(fā)生產(chǎn)率的難度，提高了軟件開發(fā)生產(chǎn)率典型的軟件生存周期需求分析軟件分析軟件設(shè)計(jì)編碼（測試）交付測試使用維護(hù)典型的軟件生存周期軟件生存周期的主要活動(dòng) 需求分析明確需要解決的問題

5、（從用戶的視角）建立需求模型：功能、性能、約束、接口等 軟件分析從開發(fā)人員的視角對(duì)軟件進(jìn)行分析建立分析模型：軟件的邏輯模型 軟件設(shè)計(jì)確定軟件的總體結(jié)構(gòu)和各部件的數(shù)據(jù)結(jié)構(gòu)和操作建立軟件設(shè)計(jì)模型：考慮實(shí)現(xiàn)技術(shù)和平臺(tái) 編碼用程序設(shè)計(jì)語言將設(shè)計(jì)文檔翻譯成源程序建立軟件實(shí)現(xiàn)模型：包含現(xiàn)有軟件構(gòu)件包 軟件測試發(fā)現(xiàn)程序中的錯(cuò)誤、提高軟件質(zhì)量單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試 運(yùn)行維護(hù)軟件過程與軟件生存周期 軟件過程軟件過程 圍繞軟件開發(fā)所進(jìn)行的一系列活動(dòng)，早期也叫圍繞軟件開發(fā)所進(jìn)行的一系列活動(dòng)，早期也叫“軟件開軟件開發(fā)模型發(fā)模型”。 軟件過程模型軟件過程模型 把軟件生存周期中軟件開發(fā)活動(dòng)的有序流程用一個(gè)

6、合理把軟件生存周期中軟件開發(fā)活動(dòng)的有序流程用一個(gè)合理的框架來規(guī)范描述。的框架來規(guī)范描述。 軟件過程模型是一種軟件過程的抽象表示法，它從一個(gè)軟件過程模型是一種軟件過程的抽象表示法，它從一個(gè)特定的角度表現(xiàn)一個(gè)開發(fā)過程。特定的角度表現(xiàn)一個(gè)開發(fā)過程。 軟件生存周期中的階段和軟件過程中的活動(dòng)是基本軟件生存周期中的階段和軟件過程中的活動(dòng)是基本一致的。一致的。2.傳統(tǒng)的軟件過程 傳統(tǒng)的過程模型瀑布模型（waterfall model）基于軟件生存周期的線性開發(fā)模型。 快速原型模型（rapid prototype model） 基于原型的迭代化開發(fā)模型。瀑布模型圖2.2 瀑布模型的階段與文檔需求分析需求規(guī)格說

7、明軟件分析與總體設(shè)計(jì)軟件結(jié)構(gòu)圖模塊說明系統(tǒng)測試確認(rèn)測試綜合測試程序清單詳細(xì)設(shè)計(jì)編 碼用戶要求單元測試nW.Royce于1970年提出n線性開發(fā)模型n強(qiáng)調(diào)軟件文檔每一個(gè)階段必須完成規(guī)定的文檔每一個(gè)階段都要復(fù)審?fù)瓿傻奈臋n瀑布模型特點(diǎn)階段的順序性（前一階段完成后才能開始下一階段）和依賴性（前一階段輸出文檔是下一階段輸入文檔）。推遲實(shí)現(xiàn)的觀點(diǎn)（不要過早編碼）。質(zhì)量保證的觀點(diǎn)（必須完成文檔并進(jìn)行復(fù)審）。存在問題不適合需求模糊的系統(tǒng)。開發(fā)初始階段很難徹底弄清軟件需求。快速原型模型需求原型開發(fā)最終系統(tǒng)設(shè)計(jì)原型評(píng)價(jià)最終系統(tǒng)實(shí)現(xiàn)用戶反饋快速原型模型 特點(diǎn) “逼真”的原型可以使用戶迅速作出反饋。循環(huán)回溯和迭代：非

8、線性模型。使用快速開發(fā)工具。 種類漸進(jìn)型：對(duì)原型補(bǔ)充和修改獲得最終系統(tǒng)。拋棄型：原型廢棄不用。 應(yīng)防止的偏向舍不得拋棄，從而影響軟件質(zhì)量。3.軟件演化模型 演化開發(fā)模型，遵循迭代的思想方法，使所開發(fā)的軟件在迭代中逐步完善。增量模型（incremental model）。螺旋模型（spiral model）。 構(gòu)件集成模型（component integration model）。增量模型把軟件看作一系列相互聯(lián)系的增量，每次迭代完成一個(gè)增量把軟件看作一系列相互聯(lián)系的增量，每次迭代完成一個(gè)增量構(gòu)件1：需求設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶構(gòu)件2：需求設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶構(gòu)件3：需求設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶構(gòu)件

9、n：需求設(shè)計(jì)實(shí)現(xiàn)和集成交付客戶規(guī)格說明組設(shè)計(jì)組實(shí)現(xiàn)和集成組增量模型 增量小而可用的軟件。第一個(gè)增量通常是軟件的核心。 特點(diǎn)在前面增量的基礎(chǔ)上開發(fā)后面的增量。每個(gè)增量的開發(fā)可用瀑布或快速原型模型。每個(gè)增量開發(fā)的順序性和總體的迭代性相結(jié)合。螺旋模型螺旋模型 特點(diǎn)瀑布模型（順序性、邊開發(fā)邊復(fù)審）+快速原型（迭代性）。適用大型軟件開發(fā)。風(fēng)險(xiǎn)分析，發(fā)現(xiàn)、控制風(fēng)險(xiǎn)。 一個(gè)螺旋式周期 計(jì)劃：確定目標(biāo)，選擇方案，選定完成目標(biāo)的策略。 風(fēng)險(xiǎn)分析：從風(fēng)險(xiǎn)角度分析該策略。 開發(fā)：啟動(dòng)一個(gè)開發(fā)活動(dòng)。 評(píng)審：評(píng)價(jià)前一步的結(jié)果，計(jì)劃下一輪的工作。 構(gòu)件集成模型 面向?qū)ο蟮幕靖拍顚?duì)象（Object）類（Class）繼承（

10、Inheritance）消息（Message ）面向?qū)ο髮?duì)象+類+繼承+消息通信 面向?qū)ο箝_發(fā)模型均可借用面向過程開發(fā)模型。構(gòu)件集成模型主要適用于面向?qū)ο蟮能浖_發(fā)。構(gòu)件集成模型 構(gòu)件在某個(gè)領(lǐng)域內(nèi)具有通用性，可以復(fù)用的軟件部件。將可以復(fù)用的構(gòu)件存儲(chǔ)起來，形成構(gòu)件庫構(gòu)件庫。 特點(diǎn)面向?qū)ο??；跇?gòu)件庫。 融合螺旋模型特征。 支持軟件開發(fā)的迭代方法 。軟件復(fù)用。構(gòu)件集成模型4.形式化方法模型 形式化方法模型，基于程序變換和驗(yàn)證技術(shù)的軟件開發(fā)。 轉(zhuǎn)換模型（transformational model）。 凈室模型（cleanroommodel）。轉(zhuǎn)換模型 開發(fā)過程確定形式化需求規(guī)格說明書。進(jìn)行自動(dòng)的程

11、序變換。針對(duì)形式化開發(fā)記錄進(jìn)行測試。 常用技術(shù) 基于模型的需求規(guī)格說明書及變換技術(shù)。 基于代數(shù)的需求規(guī)格說明書及變換技術(shù)。 基于時(shí)序邏輯的需求規(guī)格說明書和驗(yàn)證技術(shù)。 基于可視形式化的技術(shù)。 轉(zhuǎn)換模型形式化規(guī)格說明與 需 求比 較 后修正變換2變換1變換n測試形式化開發(fā)記錄系統(tǒng)需求目標(biāo)系統(tǒng)凈室模型 凈室思想在分析和設(shè)計(jì)階段消除錯(cuò)誤。在“潔凈”狀態(tài)下實(shí)現(xiàn)軟件制作。 增量模型把軟件看成一系列的增量。 形式化每一個(gè)增量用形式化表示盒，表示分析和設(shè)計(jì)。正確性驗(yàn)證。凈室模型需求收集盒結(jié)構(gòu)規(guī)約形式化設(shè)計(jì)統(tǒng)計(jì)性使用測試正確性證明代碼生成與檢查測試計(jì)劃認(rèn)證需求收集盒結(jié)構(gòu)規(guī)約形式化設(shè)計(jì)統(tǒng)計(jì)性使用測試正確性證明代碼

12、生成與檢查測試計(jì)劃認(rèn)證需求收集盒結(jié)構(gòu)規(guī)約形式化設(shè)計(jì)統(tǒng)計(jì)性使用測試正確性證明代碼生成與檢查測試計(jì)劃認(rèn)證增量1增量2增量n軟件過程模型的特點(diǎn)匯總開發(fā)模型開發(fā)模型特特 點(diǎn)點(diǎn)適用場合適用場合瀑布模型線性模型，每一階段必須完成規(guī)定的文檔需求明確的中小型軟件開發(fā)快速原型模型用戶介入早，通過迭代完善用戶需求，原型廢棄不用需求模糊的小型軟件開發(fā)增量模型每次迭代完成一個(gè)增量，可用于OO開發(fā)容易分塊的大型軟件開發(fā)螺旋模型典型迭代模型，重視風(fēng)險(xiǎn)分析，可用于OO開發(fā)具有不確定性大型軟件開發(fā)構(gòu)件集成模型軟件開發(fā)與構(gòu)件開發(fā)平行進(jìn)行領(lǐng)域工程、行業(yè)的中型軟件開發(fā)轉(zhuǎn)換模型形式化的規(guī)格說明，自動(dòng)的程序變換系統(tǒng)理想化模型，尚無成熟

13、工具支持凈室模型形式化的增量開發(fā)模型，在潔凈狀態(tài)下實(shí)現(xiàn)軟件制作開發(fā)團(tuán)隊(duì)熟悉形式化方法，中小型軟件開發(fā)課堂互動(dòng) 快速原型快速原型的的快速表現(xiàn)在哪里？實(shí)現(xiàn)快速原快速表現(xiàn)在哪里？實(shí)現(xiàn)快速原型法的最終系統(tǒng)可以有幾種方法？請說明型法的最終系統(tǒng)可以有幾種方法？請說明并加以比較。并加以比較。5. 統(tǒng)一過程和敏捷過程 統(tǒng)一過程Rational Unified Process（RUP）描述了軟件開發(fā)中各個(gè)環(huán)節(jié)應(yīng)該做什么、怎么做、什么時(shí)候做以及為什么要做，描述了一組以某種順序完成的活動(dòng)。 敏捷過程Agile Development是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法，其軟件開發(fā)過程稱為“敏捷過程”。RUPR

14、ational Unified Process 將軟件開發(fā)分為四個(gè)階段：初始初始 定義整個(gè)項(xiàng)目的范圍，是否可行。細(xì)化細(xì)化 制定項(xiàng)目計(jì)劃、描述功能、建立體系架構(gòu)框架。構(gòu)造構(gòu)造 構(gòu)造軟件產(chǎn)品。遷移遷移 將軟件產(chǎn)品移交到最終用戶手中。敏捷過程把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中軟件處于可用狀態(tài)。敏捷開發(fā)的價(jià)值觀 個(gè)人和交互勝過過程和工具。 可以運(yùn)行的軟件勝過面面俱到的文檔。 客戶合作勝過合同談判。 響應(yīng)變化勝過遵循計(jì)劃。敏捷過程敏捷開發(fā)的12條原則 盡早、不斷地提交有價(jià)值的軟件 允許改變需求，利用變化來為客戶創(chuàng)造優(yōu)勢 盡快、不斷地提交可運(yùn)行的軟件 在業(yè)務(wù)人員和開

15、發(fā)人員必須天天都在一起工作 以積極向上的員工為中心建立項(xiàng)目組，提供環(huán)境和支持，并信任他們的工作 在團(tuán)隊(duì)內(nèi)部重視面對(duì)面的交流 依據(jù)可運(yùn)行軟件來評(píng)估項(xiàng)目的進(jìn)展 提倡可持續(xù)的開發(fā) 時(shí)刻關(guān)注技術(shù)上的精益求精和好的設(shè)計(jì)，以增強(qiáng)敏捷能力 簡單是最根本的 最好的構(gòu)架、需求和設(shè)計(jì)出于自組織團(tuán)隊(duì) 每隔一定時(shí)間，要反省如何才能更有效地工作，然后作相應(yīng)調(diào)整 極限編程 eXtreme Programming是一種輕量級(jí)的、敏捷的軟件開發(fā)方法。 4個(gè)價(jià)值觀交流、簡單、反饋、勇氣 4個(gè)方面改善加強(qiáng)交流、從簡單做起、尋求反饋、勇于實(shí)事就是。 12個(gè)核心實(shí)踐完整團(tuán)隊(duì)、計(jì)劃對(duì)策、測試、簡單設(shè)計(jì)、結(jié)對(duì)編程、小軟件版本、設(shè)計(jì)改進(jìn)、

16、持續(xù)集成、代碼共有、編碼標(biāo)準(zhǔn)、系統(tǒng)比喻、可持續(xù)的速度。6.軟件可行性研究 目的研究項(xiàng)目是否可能實(shí)現(xiàn)和值得進(jìn)行。 研究的內(nèi)容經(jīng)濟(jì)可行性技術(shù)可行性運(yùn)行可行性法律可行性可行性研究的步驟 對(duì)當(dāng)前系統(tǒng)進(jìn)行調(diào)查和研究弄清當(dāng)前系統(tǒng)導(dǎo)出新系統(tǒng)邏輯模型 導(dǎo)出新系統(tǒng)的解決方案設(shè)計(jì)不同的解決方案 提出推薦的方案本項(xiàng)目的開發(fā)價(jià)值推薦這個(gè)方案的理由 編寫可行性論證報(bào)告系統(tǒng)概述可行性分析結(jié)論意見軟件風(fēng)險(xiǎn)分析 軟件開發(fā)存在風(fēng)險(xiǎn)。 風(fēng)險(xiǎn)識(shí)別項(xiàng)目風(fēng)險(xiǎn)（進(jìn)度、人力、資源、客戶）技術(shù)風(fēng)險(xiǎn)（設(shè)計(jì)、實(shí)現(xiàn)、接口、維護(hù)）商業(yè)風(fēng)險(xiǎn)（市場、策略、推銷） 建立風(fēng)險(xiǎn)項(xiàng)目檢測表產(chǎn)品規(guī)模商業(yè)影響客戶關(guān)系人員技術(shù)例：人員配備風(fēng)險(xiǎn)檢測表(1) 開發(fā)人員的

17、水平如何。(2) 開發(fā)人員在技術(shù)上是否配套。(3) 開發(fā)人員的數(shù)量如何。(4) 開發(fā)人員是否能夠自始至終地參加軟件開發(fā)工作。(5) 開發(fā)人員是否能夠集中全部精力投入到軟件開發(fā)工作。(6) 開發(fā)人員對(duì)自己的工作是否有正確的期望。(7) 開發(fā)人員是否接受過必要的培訓(xùn)。(8) 開發(fā)人員的流動(dòng)是否能夠保證工作的連續(xù)性。 上述問題可以選用0,1,2,3,4,5來回答。完全肯定取值為0，反之為5，中間情況分別取值1,2,3,4值越大表示風(fēng)險(xiǎn)越大。 人員配備風(fēng)險(xiǎn)檢測表反映了人的因素給軟件項(xiàng)目帶來的風(fēng)險(xiǎn)。風(fēng)險(xiǎn)估算 軟件項(xiàng)目管理人員可以從影響風(fēng)險(xiǎn)的因素和風(fēng)險(xiǎn)發(fā)生后的損失兩方面來度量風(fēng)險(xiǎn)。風(fēng)險(xiǎn)評(píng)價(jià)和管理三元組 r

18、i，li，xi i =1,2,3l 風(fēng)險(xiǎn)序號(hào) 其中：ri表示風(fēng)險(xiǎn)，li表示風(fēng)險(xiǎn)發(fā)生的概率 xi表示風(fēng)險(xiǎn)產(chǎn)生的影響。 由于項(xiàng)目超支、進(jìn)度拖延和軟件性能下降都會(huì)導(dǎo)致軟件項(xiàng)目的終止，對(duì)大多數(shù)軟件項(xiàng)目，分析應(yīng)都需要給出成本、進(jìn)度和性能的風(fēng)險(xiǎn)參考值，當(dāng)某一風(fēng)險(xiǎn)或風(fēng)險(xiǎn)組合值超過參考值時(shí)項(xiàng)目被迫停止。風(fēng)險(xiǎn)評(píng)價(jià)和管理三元組ri，li，xi是風(fēng)險(xiǎn)管理的基礎(chǔ) 設(shè)高級(jí)職員流動(dòng)給項(xiàng)目帶來風(fēng)險(xiǎn)ri, 根據(jù)歷史的經(jīng)驗(yàn)或直觀感覺，高級(jí)職員離開課題組的概率li = 70%, 這一風(fēng)險(xiǎn)導(dǎo)致事件xi發(fā)生 項(xiàng)目開發(fā)時(shí)間延長 15%，成本增加 20%項(xiàng)目負(fù)責(zé)人采取的風(fēng)險(xiǎn)管理措施(1)項(xiàng)目開始前控制產(chǎn)生風(fēng)險(xiǎn)的原因。項(xiàng)目開工后應(yīng)設(shè)法減輕

19、風(fēng)險(xiǎn)的影響。(2)了解項(xiàng)目開發(fā)人員變動(dòng)的原因，在項(xiàng)目開發(fā)期間應(yīng)控制上述原因，盡量減少人員的流動(dòng)。(3)在工作方法和技術(shù)上采取適當(dāng)措施，防止因人員流動(dòng)給工作帶來損失。(4)項(xiàng)目在開發(fā)過程中應(yīng)及時(shí)公布并交流項(xiàng)目開發(fā)的信息。(5)建立組織機(jī)構(gòu)，確定文檔標(biāo)準(zhǔn)、并及時(shí)生成文檔。(6)對(duì)工作進(jìn)行集體復(fù)審，使多數(shù)人都能了解工作的細(xì)節(jié)，跟上工作進(jìn)度。(7)為關(guān)鍵技術(shù)準(zhǔn)備后備人員。風(fēng)險(xiǎn)緩解、監(jiān)控和管理計(jì)劃 風(fēng)險(xiǎn)緩解、監(jiān)控和管理計(jì)劃 Risk Mitigation,Monitoring,and Management Plan 將風(fēng)險(xiǎn)分析工作文檔化，成為項(xiàng)目的一部分。 執(zhí)行RMMM計(jì)劃需要成本 當(dāng)軟件項(xiàng)目比較大時(shí)，可能標(biāo)出30至40種風(fēng)險(xiǎn)，如果為每種風(fēng)險(xiǎn)定義3至7種風(fēng)險(xiǎn)管理步驟，則風(fēng)險(xiǎn)管理本身就是一個(gè)項(xiàng)目。項(xiàng)目實(shí)施計(jì)劃 軟件