講座5項目方法選擇ppt課件

1、第5講 工程方法選擇技術選擇技術選擇將影響：開發(fā)人員的訓練需求人員招聘開發(fā)環(huán)境硬件和軟件系統(tǒng)維護安排步驟：分析工程是目的驅動的還是產(chǎn)品驅動的分析工程其他特征面向數(shù)據(jù)還是面向控制通用還是公用能否涉及需求公用工具支持的專門技術能否有特殊的平安性要求對軟硬件有何要求練習對以下系統(tǒng)進展分類工資支付系統(tǒng)飲料灌裝企業(yè)的控制系統(tǒng)供水企業(yè)管理對企業(yè)供水方案的系統(tǒng)支持工程管理的軟件供律師查詢法律條文的系統(tǒng)面向數(shù)據(jù)或特定領域的運用系統(tǒng)包含嵌入式軟件的過程控制或者工業(yè)系統(tǒng)運用圖形的信息系統(tǒng)通用信息系統(tǒng)軟件包信息搜集的通用軟件包識別工程中的高風險產(chǎn)品不確定性：系統(tǒng)需求了解的準確性。用戶在開場時有能夠對系統(tǒng)應該什么樣都

2、無法確定。在某些環(huán)境中，準確而有效的需求描畫能夠迅速變得過時。過程不確定性：在工程開場時需求選擇方法或過程模型，或者一種新的工具，任何對原先采用的開發(fā)方法的變化都將引入不確定性資源不確定性：工程進展中資源的數(shù)量能夠發(fā)生變化練習識別學院工資系統(tǒng)中的風險金融和職員之間的矛盾職員對系統(tǒng)不接受短少運轉該系統(tǒng)的閱歷短少管理系統(tǒng)的計算機專業(yè)人員需求變化選擇方法思索用戶關于實現(xiàn)的需求用戶能夠在合同中限定了有關實現(xiàn)方面的方法。例如，規(guī)定了企業(yè)必需具有相應的CMM等級，或者經(jīng)過了ISO9000方法選擇通用的生命周期方法控制系統(tǒng)：普通為實時系統(tǒng)，比如需求Petri網(wǎng)技術信息系統(tǒng)：Too often, softwa

3、re work follows the first law of bicycling: No matter where youre going, its uphill and against the wind過程模型的選擇開發(fā)一個軟件需求選擇開發(fā)戰(zhàn)略包括過程，方法和工具以及通用階段，這些戰(zhàn)略和階段被稱為過程模型“過程：相關聯(lián)的活動過程模型的選擇基于工程和運用的特性，運用的工具和方法，所需求的控制方法和交付物。問題求解的普經(jīng)過程問題求解的普經(jīng)過程實踐問題并不能簡單劃為四個階段，各個階段會在問題的不同層次上同時并存軟件開發(fā)實踐上是一個“混沌chaos過程Raccoon問題定義方案集成技術開發(fā)現(xiàn)狀編

4、碼修正模型Code and Fix Code like Hell(魯莽編碼)從一個大致的想法開場任務，然后經(jīng)過非正規(guī)的設計、編碼、調試和測試方法，最后完成任務能夠有能夠沒有的規(guī)范發(fā)布能夠編碼修正模型益處：本錢能夠很低只需求很少的專業(yè)知識，任何寫過程序的人都可以對于一些非常小的、開發(fā)完后就會很快丟棄的軟件可以采用對于規(guī)模稍大的工程，采用這種模型是很危險的瀑布模型Waterfall Model)一切過程模型的祖宗工程從開場到終了按照一定的順序執(zhí)行瀑布模型是文檔驅動的，各個階段不延續(xù)也不交叉瀑布模型發(fā)瀑布模型順應于什么場所？有何優(yōu)缺陷？瀑布模型當有一個穩(wěn)定的產(chǎn)品定義和很容易被了解的技術處理方案時，純

5、瀑布模型特別適宜當他對一個定義得很好的版本進展維護或將一個產(chǎn)品移植到一個新的平臺上，瀑布模型也特別適宜。純瀑布模型可以降低管理費用，由于他可以預先完成一切方案。對于那些容易了解但很復雜的工程，采用純瀑布模型比較適宜，由于可以用順序方法處置問題。在質量需求高于本錢需求和進度需求的時候，它尤為出色。當開發(fā)隊伍的技術力量比較弱或者缺乏閱歷時，瀑布模型更為適宜。瀑布模型純瀑布模型的缺陷是在工程開場的時候，在設計任務完成前和代碼寫出來前，很難充分描畫需求。瀑布模型最主要的問題是缺乏靈敏性。必需在工程開場前闡明全部需求。但這恰恰是非常困難的。瀑布模型變種：V型模型該方法是對瀑布模型的修正，強調了驗證活動瀑

6、布模型變種：生魚片模型把階段重疊起來的瀑布模型來源于日本硬件開發(fā)模型富士通施樂軟件概念需求分析架構設計詳細設計編碼和調試系統(tǒng)測試瀑布模型變種：生魚片模型傳統(tǒng)的瀑布模型強調階段之間最小的重疊，而生魚片模型強調大幅度的重疊，即在需求分析完成之前就可以進展架構設計和部分詳細設計純瀑布模型強調在恣意兩個階段交接時，文檔從一個團隊交給另一個完全隔離的團隊，但是假設一個團隊完成各個階段義務時，可以沒有那么多文檔。問題：缺陷是什么？生魚片模型由于階段重疊，因此里程碑不明確，很難有效地進展過程跟蹤和控制。瀑布模型變種：具有子工程的瀑布模型純瀑布模型的一個問題是必需完成全部的架構設計后才干進展詳細設計，但是，整

7、個系統(tǒng)中有些部分能夠有些特殊性，可以有本人的步驟，即將這些部分劃分為為子工程。問題：該模型有何問題？這種方法的主要風險是相關性無法預料。瀑布模型變種：可以降低風險的瀑布模型純瀑布模型要求在開場架構設計前，必需將用戶的一切需求都搞清楚，但是實踐中是很困難的?？山档惋L險的瀑布模型是在頂端，即需求分析和架構設計階段引入螺旋以便降低風險。在該螺旋中，先開發(fā)一個用戶界面原型，采用系統(tǒng)情節(jié)串聯(lián)圖版system storyboarding引導用戶提出需求，記錄用戶與系統(tǒng)的交互操作方式，或者采用其它需求獲取方法。螺旋模型Spiral 模型Boehm提出以風險為導向的生命期模型從一個小范圍的關鍵中心地帶開場尋覓

8、風險要素，制定風險控制方案，并交付給下一步驟，如此迭代，每次迭代將工程擴展到一個更大的規(guī)模問題：有何優(yōu)缺陷？螺旋模型優(yōu)勢：隨著迭代的添加本錢的添加，風險程度隨之降低缺陷：比較復雜，需求責任心，專注和管理方面的知識。WINWIN螺旋模型在螺旋模型中，經(jīng)過與客戶的通訊獲取客戶的需求，實踐上，客戶的需求與最終確定的需求是不一致的，客戶與開發(fā)者之間需求進展協(xié)商，最終到達雙贏的局面。Boehm提出的WINWIN螺旋模型中，客戶與開發(fā)者之間需求識別系統(tǒng)或子系統(tǒng)的關鍵涉及者stakeholders確定涉及者的“win conditions對這些條件進展協(xié)商獲得互贏條件WINWIN螺旋模型WINWIN螺旋模型

9、還引入了三個過程的里程碑，被稱為定位點Anchor points生命周期目的life cycle objectives定義了每個主要活動的目的生命周期體系構造life cycle architecture定義了系統(tǒng)和軟件的體系構造目的初步操作才干initial operational capability定義了軟件安裝，發(fā)布的目的。并行開發(fā)模型并行開發(fā)模型concurrent development model又被稱為并行工程concurrent engineeringBy Davis and Sitaram軟件開發(fā)中的一切活動能夠同時并存，但是都處于不同的形狀中并行開發(fā)模型定義了活動從一個形

10、狀轉化為另一個形狀的事件并行開發(fā)模型NoneAwaiting changesUnder revisionUnder reviewBaselinedDoneUnder developmentAnalysis activity并行開發(fā)模型并行過程模型經(jīng)常被用于開發(fā)C/S系統(tǒng)。該系統(tǒng)的活動可以被分為系統(tǒng)維和部件維。系統(tǒng)維包含了設計，裝配和運用三個活動，而部件維包含了設計和實現(xiàn)兩個活動。并發(fā)性表如今兩個方面：系統(tǒng)和部件的活動同時發(fā)生各個部件可以并行設計和開發(fā)原型法原型法原型是工程系統(tǒng)中的一個方面或者多個方面的任務模型。丟棄型原型：用于實驗某些概念，實驗完系統(tǒng)將無用途進化型原型：原型系統(tǒng)不斷被開發(fā)和被修

11、正，最終它變?yōu)橐粋€真正的系統(tǒng)。原型法原型的益處從實際中學習(Learning by doing)改善的通訊改善的用戶參與使部分知的需求明晰化展現(xiàn)描畫的一致性和完好性能夠可以減少文檔減少了維護本錢特征約束利用工具構造原型可以將某些特性落到實處，而非在紙上寫的那樣容易失誤實驗能否能產(chǎn)生等待的結果原型法原型法的缺陷用戶有時誤解了原型的角色，例如他們能夠誤解原形應該和真實系一致樣可靠短少工程規(guī)范，進化原型法有點像編碼修正短少控制，由于用戶能夠不斷提出新要求，因此原型迭代的周期很難控制額外的破費：研討結果闡明構造一個原型能夠需求10%額外破費運轉效率能夠會受影響原型法要求開發(fā)者與用戶親密接觸，有時這是不

12、能夠的。例如外包軟件。從另外的角度對待原型從中學到什么？學生經(jīng)常會做一些軟件作業(yè)，這些作業(yè)被稱為原型，問題：這些原型和軟件系統(tǒng)原型能否一樣？但是作為一個原型必需：描畫他們希望從中學到的東西，規(guī)劃原型評價的方法，報告從原型中真正學到的內(nèi)容。在不同的階段，原型具有不同的作用。原型起作用的程度實物模型Mock-ups仿真交互部分模型：程度，垂直某些特性構造詳細的原型構造原型的對象人機接口系統(tǒng)的功能練習：何時引入原型系統(tǒng)保險公司的經(jīng)理需求經(jīng)過個人計算機上的一個系統(tǒng)來訪問管理信息。該系統(tǒng)價錢必需適宜。很多人疑心能否經(jīng)理真需求運用該系統(tǒng)?？尚行匝杏戨A段，采用實物模型的方法支持客戶銷售人員經(jīng)過回答有關客戶訊

13、問汽車保險價錢的系統(tǒng)設計用戶對話界面時保險公司思索實施一個基于MS Access的銷售系統(tǒng)，他們不知道Access能否可以開發(fā)出相應界面的系統(tǒng)并具備足夠快的相應時間。方案設計階段階段交付階段交付繼續(xù)地在確定的階段向用戶展現(xiàn)軟件。和漸進原型不同，在階段交付的時候，他明確地知道下一步要完成什么任務。階段交付的特點是不會在工程終了的時候一下交付全部軟件，而是在工程整個開發(fā)過程中繼續(xù)不斷地交付階段性成果。階段交付軟件概念需求分析構架設計階段1：詳細設計，編碼，調試，階段2：詳細設計，編碼，調試，階段交付階段交付的優(yōu)點是工程終了交付全部成果前，分階段將有用的功能交付給用戶。階段交付的主要缺陷是，假設管理

14、層面和技術層面上缺乏仔細的規(guī)劃，任務就無法進展。運用階段交付的留意點是：必需確定每一階段的交付是對用戶有用的必需確保思索了不同產(chǎn)品組成部分的技術依賴關系面向進度的設計類似于階段交付，但是面向進度的設計生命周期模型在開場的時候不用知道終究能到達何目的，但是要確保最后的期限。該模型的關鍵是要按優(yōu)先級別劃分系統(tǒng)特性并規(guī)劃開發(fā)階段，保證前面的階段具有高優(yōu)先級的特性，低特性具有低優(yōu)先級別。能否采用這種方法決議于他能否對系統(tǒng)目的具有足夠的自信心，假設有自信心，那么沒必要采用這種方法。漸進交付漸進交付是一種跨越了漸進原型和階段交付兩種模型的過程模型。根本過程：開發(fā)一個產(chǎn)品的版本，展現(xiàn)給用戶，根據(jù)反響改善產(chǎn)品

15、。假設方案滿足用戶的絕大部分需求，漸進交付與漸進原型差不多，假設方案滿足少量的需求，漸進交付就和階段交付差不多。漸進原型，強調的是系統(tǒng)看得見的樣子，再回來堵破綻，漸進交付中，最初的重點是系統(tǒng)中心和底層系統(tǒng)功能。漸進交付軟件概念需求分析構架和內(nèi)核設計開發(fā)一個版本并入用戶反響交付該版本開發(fā)一個版本交付最終版本確定漸進交付目的的一種方法價值本錢比面向開發(fā)工具的設計只在現(xiàn)有軟件工具直接支持的情況下加強產(chǎn)品的功能，假設它不支持，就放棄這些功能。當時間成為主要約束時，采用該模型可以比其他模型可以更完好地實現(xiàn)功能。該方法的缺陷是他失去了很多對產(chǎn)品的控制才干。商品軟件商品軟件也許未必滿足他一切的要求，但是本人開發(fā)也需求一個周期，到那個時候，商品軟件能夠曾經(jīng)滿足了他的要求。商品軟件能夠存在缺乏，但是，他本人開發(fā)的產(chǎn)品也未必那么完美，當他補充了商品軟件的缺乏時，也許帶來了新的問