PPT3軟件過程軟件過程模型瀑布模型：每個過程階段獨(dú)立，直到上一個過程完成，下一個過程才啟動其間伴隨著過程反復(fù)瀑布模型的缺點(diǎn)是過程進(jìn)行中對應(yīng)變更比較困難。問題：將項(xiàng)目生硬地劃分成幾個明顯不同的階段，這使得響應(yīng)客戶的需求比較困難，所以這個模型適用于需求能夠較好地理解的情況進(jìn)化式開發(fā)：描述與開發(fā)交替進(jìn)行探索式：其目標(biāo)是與客戶一起工作，從最初的需求草案進(jìn)化到最后的系統(tǒng)。應(yīng)該從理解最清楚的需求開始。拋棄式：目的是理解系統(tǒng)需求。從理解較差的需求開始問題：缺乏過程可見性；系統(tǒng)結(jié)構(gòu)通常較差；需要特殊的工具和技術(shù)(例如采用快速建立原型的語言)適用性：中小型交互式系統(tǒng)；大型系統(tǒng)的一部分(如用戶界面)；生命周期短的系統(tǒng)形式化的系統(tǒng)開發(fā)基于用形式化數(shù)學(xué)轉(zhuǎn)換將系統(tǒng)描述轉(zhuǎn)換成一個可執(zhí)行程序轉(zhuǎn)換是保證正確性的，所以程序是符合描述的。具體實(shí)現(xiàn)如IBM的凈室(Cleanroom)過程軟件開發(fā)問題：應(yīng)用這項(xiàng)技術(shù)需要專門的技能和訓(xùn)練；系統(tǒng)的某些方面難以形式化描述，例如用戶界面適應(yīng)性：適合于嚴(yán)格的系統(tǒng)，特別是安全性和保密性要求極高的系統(tǒng)面向復(fù)用的開發(fā)基于已有的組件或者COTS系統(tǒng)的系統(tǒng)重用過程反復(fù)：系統(tǒng)需求在項(xiàng)目進(jìn)行期間總是進(jìn)化的，所以對大型系統(tǒng)來說經(jīng)常是早期階段反復(fù)的過程；反復(fù)可以應(yīng)用于任何通用過程模型兩個混合模型增量式開發(fā)：系統(tǒng)不是一次交付，而是將要求的功能分成多次增量進(jìn)行開發(fā)和交付用戶需求是有優(yōu)先順序的。優(yōu)先級最高的需求包含在最初的增量中。一旦一個增量的開發(fā)開始時，需求就要凍結(jié)。雖然后面的增量可以繼續(xù)進(jìn)化優(yōu)勢：客戶要求的功能隨著每次增量被交付，所以系統(tǒng)功能可以較早看到較早的增量可以作為原型幫助引出后面增量的需求項(xiàng)目總體失敗的風(fēng)險降低最高優(yōu)先級的系統(tǒng)服務(wù)由于是最早增量，得到最多的測試極限編程：基于非常小的功能增量的開發(fā)和交付的一種新的方法；依靠連續(xù)的代碼改進(jìn)，用戶參與到開發(fā)團(tuán)隊(duì)一起開發(fā)，是敏捷開發(fā)的一種螺旋式開發(fā)將過程表示為螺旋線，而不是用一系列活動和活動間的回溯來表示螺旋線中的每個回路表示過程中的一個階段沒有固定的階段。螺旋線中的回路根據(jù)需要選取風(fēng)險需要明確評估、然后在過程中解決軟件設(shè)計(jì)方法數(shù)據(jù)流模型：包括數(shù)據(jù)元素，數(shù)據(jù)操作，數(shù)據(jù)流向?qū)嶓w-關(guān)系模型結(jié)構(gòu)模型對象模型：將數(shù)據(jù)與操作封裝視為對象，具有一定的屬性，各個對象之間連線構(gòu)成模型PPT4項(xiàng)目管理軟件項(xiàng)目管理涉及的行為，是為了確保軟件及時并按照進(jìn)度的要求交付，同時滿足開發(fā)或者采購該軟件的機(jī)構(gòu)的需求項(xiàng)目管理是需要的，因?yàn)檐浖_發(fā)總是受到預(yù)算和進(jìn)度的約束，這些約束是由開發(fā)該軟件的機(jī)構(gòu)所設(shè)置的。軟件管理的特別之處：產(chǎn)品是無形的產(chǎn)品是靈活可變的，其它產(chǎn)品中這是比較少見的。軟件工程學(xué)科被認(rèn)為還是不完整的，跟機(jī)械、電子工程等學(xué)科不同軟件開發(fā)過程是非標(biāo)準(zhǔn)化的許多軟件項(xiàng)目是一次性的項(xiàng)目項(xiàng)目計(jì)劃的類型：質(zhì)量計(jì)劃，有效性驗(yàn)證計(jì)劃，配置管理計(jì)劃（支持系統(tǒng)的集成計(jì)劃，使每個開發(fā)人員可以在管理中訪問工程代碼和文檔，超找變更，編譯連接組件并生成系統(tǒng)），維護(hù)計(jì)劃，人員發(fā)展計(jì)劃活動組織里程碑：是一個過程活動的終點(diǎn)，瀑布過程可以定義明顯的進(jìn)度里程碑可交付物：是交付給客戶的項(xiàng)目結(jié)果項(xiàng)目調(diào)度將項(xiàng)目分解成多個任務(wù)，估算完成每個任務(wù)需要的時間和資源并發(fā)地組織任務(wù)以形成勞動力的優(yōu)化利用使得任務(wù)間的依賴性最小化以避免一個任務(wù)等待另一個任務(wù)帶來的延遲依賴于項(xiàng)目管理者的直覺和經(jīng)驗(yàn)甘特圖：活動的時間條形圖風(fēng)險管理風(fēng)險包括項(xiàng)目風(fēng)險、產(chǎn)品風(fēng)險和業(yè)務(wù)風(fēng)險過程：風(fēng)險識別：識別項(xiàng)目、產(chǎn)品和業(yè)務(wù)風(fēng)險風(fēng)險分析：評估這些風(fēng)險出現(xiàn)的可能性及其后果風(fēng)險規(guī)劃：制訂計(jì)劃說明如何規(guī)避風(fēng)險或降低風(fēng)險對項(xiàng)目的影響風(fēng)險監(jiān)控：監(jiān)控整個項(xiàng)目過程中的風(fēng)險管理者要扮演多種角色，其中最主要的活動是規(guī)劃、估算和進(jìn)度PPT5需求工程：建立用戶需求以及使用和開發(fā)的約束的過程需求工程過程中生成的需求本身是系統(tǒng)服務(wù)和約束的描述需求的雙重功能：可能是一個合同標(biāo)書的基礎(chǔ)–所以必須公開解釋可能是合同本身的基礎(chǔ)–所以必須詳細(xì)定義這兩種情形都可能稱為需求需求的類型：用戶需求：關(guān)于系統(tǒng)服務(wù)和約束的自然語言加上方塊圖表述。為客戶撰寫。較為粗略。系統(tǒng)需求：一個結(jié)構(gòu)化的文檔寫出系統(tǒng)的服務(wù)。作為客戶和承包商之間的合同內(nèi)容。較為細(xì)致。軟件描述：一個詳細(xì)的軟件描述可以作為設(shè)計(jì)或?qū)崿F(xiàn)的基礎(chǔ)。為開發(fā)人員撰寫。功能與非功能需求功能需求：系統(tǒng)需要提供的服務(wù)的表述，系統(tǒng)應(yīng)該如何響應(yīng)特定輸入，系統(tǒng)在特定的情形下應(yīng)該如何動作。非功能需求：系統(tǒng)提供的服務(wù)或功能上的約束，例如時間約束、開發(fā)過程約束、標(biāo)準(zhǔn)等。領(lǐng)域需求：需求從系統(tǒng)應(yīng)用領(lǐng)域中得出，反映了領(lǐng)域的特征。需求應(yīng)該具有完整性和一致性完整性：需要的所有服務(wù)都應(yīng)該給出描述一致性：在系統(tǒng)服務(wù)的描述上應(yīng)該沒有沖突和矛盾非功能需求分類產(chǎn)品需求：描述交付產(chǎn)品的行為，如執(zhí)行速度、可靠性等機(jī)構(gòu)需求：機(jī)構(gòu)政策和程序的結(jié)果，如過程標(biāo)準(zhǔn)、實(shí)現(xiàn)要求外部需求：系統(tǒng)外部因素和開發(fā)過程，如互操作性要求、法律要求等需求的度量：領(lǐng)域需求從使用領(lǐng)域中得到，描述反映領(lǐng)域的特征和性質(zhì)可能是新的功能需求、已有需求的約束或者定義一個特定的計(jì)算如果領(lǐng)域需求不被滿足，系統(tǒng)可能無法工作如：問題：易懂性不夠：需求使用應(yīng)用領(lǐng)域中的語言表達(dá)；開發(fā)系統(tǒng)的軟件工程師往往無法理解不夠清晰明了：領(lǐng)域?qū)＜夷軌蚝芎玫睦斫忸I(lǐng)域知識所以他們不愿把領(lǐng)域需求表達(dá)得更加清晰明了用戶需求：應(yīng)該描述功能性和非功能性需求，使得沒有具體的技術(shù)知識的系統(tǒng)用戶也能理解用戶需求用自然語言、表和方塊圖定義自然語言的問題：不夠清楚：為了使得文檔易讀，保證精確性是困難的需求混亂：功能性和非功能性需求會混在一起需求合并：幾個不同的需求可能放在一起表達(dá)系統(tǒng)需求比用戶需求更詳細(xì)的描述作為系統(tǒng)設(shè)計(jì)的基礎(chǔ)可以作為系統(tǒng)合同的一部分系統(tǒng)需求可用結(jié)構(gòu)化的自然語言、PDL或者格式化的語言來撰寫需求和設(shè)計(jì)：自然語言的問題：二義性：需求的讀者和作者必需對同一詞語有同樣的解釋。自然語言是做到這點(diǎn)比較困難，因?yàn)樽匀徽Z言存在二義性。隨意性太大：同一件事情可能在描述中用好幾種不同的方式講述.模塊化不夠：自然語言的結(jié)構(gòu)不足以構(gòu)建系統(tǒng)需求改用結(jié)構(gòu)化的語言描述需求文檔需求文檔是對系統(tǒng)開發(fā)者要求的正式表述應(yīng)該包括系統(tǒng)定義和需求描述不是設(shè)計(jì)文檔，陳述的是系統(tǒng)應(yīng)該做什么而不是怎么做。IEEE需求標(biāo)準(zhǔn)PPT6需求工程過程共通的過程：需求導(dǎo)出，需求分析，需求驗(yàn)證，需求管理可行性研究決定一個建議的系統(tǒng)是否值得做導(dǎo)出和分析也叫需求導(dǎo)出或者需求發(fā)現(xiàn)相關(guān)的技術(shù)人員和客戶一起工作以發(fā)現(xiàn)應(yīng)用領(lǐng)域、系統(tǒng)提供的服務(wù)、系統(tǒng)的運(yùn)行限制可能涉及終端用戶、管理者、維護(hù)工程師、領(lǐng)域?qū)＜业软?xiàng)目相關(guān)人員。需求分析有三種活動區(qū)分.識別實(shí)體之間的結(jié)構(gòu)關(guān)系提取.識別實(shí)體中的一般特性發(fā)散.識別看一個問題的不同方式面向視點(diǎn)的需求導(dǎo)出項(xiàng)目相關(guān)人員不同的問題視點(diǎn)，這種多視點(diǎn)的分析是重要的，因?yàn)榉治鱿到y(tǒng)需求沒有單個正確的方式過程模型：視點(diǎn)識別：發(fā)現(xiàn)接收系統(tǒng)服務(wù)的視點(diǎn)，以及識別每個視點(diǎn)提供的服務(wù)視點(diǎn)組織：組織相關(guān)的視點(diǎn)形成層次結(jié)構(gòu)。通用的放在較高的層次。視點(diǎn)文檔：對被識別的視點(diǎn)和服務(wù)描述的精煉。視點(diǎn)系統(tǒng)映射：將分析轉(zhuǎn)化為面向?qū)ο蟮脑O(shè)計(jì)橢圓.來自視點(diǎn)和交付給視點(diǎn)的數(shù)據(jù)控制信息從每個方框的頂部出入數(shù)據(jù)從每個方框的右側(cè)出來異常顯示在方框的底部場景完成后預(yù)期的下一個事件的名稱表示在一個粗線框中用例序列圖：目錄管理的序列圖序列圖中：方塊表示活動，橫向箭頭表示轉(zhuǎn)移，縱向直線表示時間需求的有效性驗(yàn)證證明系統(tǒng)中定義的需求是客戶真正想要的需求錯誤的代價是很高的，所以有效性驗(yàn)證非常重要需求有效性驗(yàn)證技術(shù)：需求評審：對需求做系統(tǒng)性的手工分析原型開發(fā)：用一個可執(zhí)行的系統(tǒng)模型來檢查需求。在第8章詳述測試案例生成：檢查需求的易測性自動一致性分析：檢查結(jié)構(gòu)化需求描述的一致性需求管理過程包括規(guī)劃和變更管理PPT7系統(tǒng)模型一系統(tǒng)建模系統(tǒng)建模有助于分析者理解系統(tǒng)功能，模型可用來和客戶溝通不同的模型從不同的角度來描述系統(tǒng)從外部來看，是對系統(tǒng)上下文或系統(tǒng)環(huán)境建模從行為來看，是對系統(tǒng)行為建模從結(jié)構(gòu)上看，是對系統(tǒng)的體系結(jié)構(gòu)和系統(tǒng)處理的數(shù)據(jù)的結(jié)構(gòu)建模二系統(tǒng)模型類型數(shù)據(jù)處理模型，說明數(shù)據(jù)在不同的階段