精品課程《軟件工程》PPT課件-

1、軟件工程軟件工程第一章 概述使用規(guī)范說明圖表應(yīng)用強(qiáng)調(diào)背景文本和線條陰影標(biāo)題文本填充強(qiáng)調(diào)超鏈接已訪超鏈接標(biāo)準(zhǔn)配色單擊此處添加標(biāo)題單擊添加目錄內(nèi)容1單擊添加目錄內(nèi)容2單擊添加目錄內(nèi)容3單擊添加目錄內(nèi)容4單擊添加目錄內(nèi)容5單擊添加目錄內(nèi)容6單擊添加目錄內(nèi)容7一、軟件定義軟件程序文檔數(shù)據(jù)程序按事先設(shè)計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)能使程序正常操作信息的數(shù)據(jù)結(jié)構(gòu)文檔與程序開發(fā)、管理、維護(hù)和使用有關(guān)的圖文資料二、軟件的特點和分類軟件是一個邏輯實體，而不是具體的物理實體，因而具有抽象性軟件生產(chǎn)與硬件生產(chǎn)不同，沒有明顯的制造過程軟件不會用壞，但比較難維護(hù)軟件本身是復(fù)雜的，使人類能夠創(chuàng)造的最復(fù)雜的產(chǎn)物123

2、4軟件本身成本昂貴5軟件分類見表1.26三、軟件危機(jī)1、什么是軟件危機(jī)： 如何開發(fā)軟件，以滿足不斷增長，日趨復(fù)雜的需求；如何維護(hù)數(shù)量不斷膨脹的軟件產(chǎn)品。軟件開發(fā)成本和進(jìn)度的估算常常不準(zhǔn)確用戶對完成的軟件系統(tǒng)不滿意現(xiàn)象經(jīng)常發(fā)生軟件產(chǎn)品的質(zhì)量往往靠不住； Bug一大堆軟件常常是不可維護(hù)的軟件通常沒有適當(dāng)?shù)奈臋n資料2、軟件危機(jī)的表現(xiàn)軟件成本在計算機(jī)系統(tǒng)成本中所占的比例逐年上升軟件開發(fā)生產(chǎn)率提高的速度遠(yuǎn)遠(yuǎn)跟不上硬件的發(fā)展和人們需求的增長軟件本身特點：邏輯部件：管理和控制軟件開發(fā)過程相當(dāng)困難，較難維護(hù)規(guī)模龐大：代碼長度不正比程序復(fù)雜程度軟件產(chǎn)品的質(zhì)量往往靠不??； Bug一大堆軟件常常是不可維護(hù)的軟件通常

3、沒有適當(dāng)?shù)奈臋n資料軟件成本在計算機(jī)系統(tǒng)成本中所占的比例逐年上升軟件開發(fā)生產(chǎn)率提高的速度遠(yuǎn)遠(yuǎn)跟不上硬件的發(fā)展和人們需求的增長3、產(chǎn)生軟件危機(jī)的原因單擊此處添加標(biāo)題文字內(nèi)容文字內(nèi)容文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊此處添加標(biāo)題單擊此處添加標(biāo)題段落一單擊添加內(nèi)容文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字

4、內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加標(biāo)題單擊添加單擊添加單擊添加單擊添加單擊添加單擊添加內(nèi)容文字單擊添加單擊添加內(nèi)容文字單擊添加單擊添加內(nèi)容文字單擊添加單擊添加內(nèi)容文字單擊此處添加標(biāo)題單擊此處添加標(biāo)題文字內(nèi)容文字內(nèi)容文字內(nèi)容雙擊添加標(biāo)題文字單擊此處添加標(biāo)題此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字1234567雙擊添加標(biāo)題文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字雙

5、擊添加標(biāo)題文字單擊此處添加標(biāo)題單擊添加內(nèi)容文字單擊此處添加標(biāo)題單擊添加圖片標(biāo)題文字單擊此處添加標(biāo)題單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容文字內(nèi)容文字內(nèi)容文字內(nèi)容單擊此處添加標(biāo)題標(biāo)題一標(biāo)題二標(biāo)題三 標(biāo)題四內(nèi)容一內(nèi)容二內(nèi)容三內(nèi)容四內(nèi)容五內(nèi)容六內(nèi)容七標(biāo)示符號單擊此處添加標(biāo)題單擊添加標(biāo)題文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字。單擊此處添加標(biāo)題此處添加標(biāo)題單

6、擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊添加段落文字單擊此處添加標(biāo)題單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容雙擊添加標(biāo)題文字單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容雙擊添加標(biāo)題文字單擊此處添加標(biāo)題內(nèi)容標(biāo)題單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容單擊此處添加段落文字內(nèi)容內(nèi)容內(nèi)容此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文字此處添加內(nèi)容單擊添加段落文字單擊添加段落文

7、字The end謝謝 本次課程到此結(jié)束25軟件生存周期及模型第二章26一、軟件工程研究內(nèi)容序號研究方面具體內(nèi)容1軟件開發(fā)模型如：瀑布模型、增量模型、迭代模型2軟件開發(fā)方法如：面向過程方法、面向數(shù)據(jù)方法、面向?qū)ο蠓椒?軟件支持過程如：CASE工具Rose、北大青鳥系統(tǒng)、PowerDesigner4軟件管理過程如：ISO9000、CMM、軟件企業(yè)文化271、軟件生存周期(Life cycle) 軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。 軟件生存周期通常包括可行性研究和項目開發(fā)計劃、需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼、測試、維護(hù)等活動（GB8567中規(guī)定）。28定義分析藍(lán)圖、圖表、庫存、采

8、購單等設(shè)計實現(xiàn)產(chǎn)品292、軟件生存周期模型概念模型是為了理解事物而對事物作出的一種抽象，它忽略了不必要的細(xì)節(jié)，是事物的一種抽象形式 。軟件生存周期模型是描述軟件開發(fā)過程中各種活動如何執(zhí)行的模型。它確立了軟件開發(fā)和演繹中各階段的次序以及各階段活動的準(zhǔn)則，確立開發(fā)過程所必須遵守的規(guī)定和限制等。目前有瀑布模型、增量模型、螺旋模型、噴泉模型、變換模型和基于知識的模型等。2022/7/19303、軟件工程的傳統(tǒng)途徑瀑布模型(Waterfall Model) 維 護(hù)開發(fā)定義DefinitionFeasibility StudyRequirements AnalysisProgram DesignCodin

9、g & Module TestingIntegration & System TestingDelivery & MaintenanceSystem Design31二、瀑布模型瀑布模型1970年由W.Royce提出瀑布模型是傳統(tǒng)軟件工程的基礎(chǔ)。瀑布模型的基本思想是將軟件生命周期劃分為若干明確定義的階段。每一階段活動具有嚴(yán)格性，要實施評審工作，以便及早發(fā)現(xiàn)錯誤，改正錯誤 ；以文檔形式驅(qū)動的，上一階段的結(jié)果作為本階段的輸入 ；軟件維護(hù)報告要求定義確認(rèn)設(shè)計確認(rèn)編碼確認(rèn)測試確認(rèn)維護(hù)確認(rèn)測試報告源程序清單設(shè)計說明書需求說明書321、軟件定義時期基本任務(wù)：回答 要解決的問題是什么？該問題有行的通的解決辦

10、法嗎？若有解決問題的辦法，則需要多少費用、資源、時間？結(jié)束標(biāo)準(zhǔn)：提出關(guān)于問題性質(zhì)、工程目標(biāo)和規(guī)模的問題定義書面報告；提出可行性研究報告；若問題值得去解決，制定項目開發(fā)計劃?？尚行匝芯亢晚椖块_發(fā)計劃需求分析基本任務(wù)：回答“為了解決這個問題，目標(biāo)系統(tǒng)必須做什么”，確定目標(biāo)系統(tǒng)的功能。結(jié)束標(biāo)準(zhǔn)：給出軟件需求說明書332、軟件開發(fā)時期系統(tǒng)設(shè)計概要設(shè)計基本任務(wù)：回答 “概括地說，應(yīng)如何解決這個問題”。把確定的各項功能需求轉(zhuǎn)換成需要的體系結(jié)構(gòu)。設(shè)計軟件的結(jié)構(gòu)，確定程序由哪些模塊組成及模塊間的關(guān)系，同時設(shè)計該項目的應(yīng)用系統(tǒng)的總體數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫結(jié)構(gòu)。結(jié)束標(biāo)準(zhǔn)：給出概要設(shè)計文檔。詳細(xì)設(shè)計基本任務(wù)：回答 “應(yīng)怎

11、樣具體地實現(xiàn)這個系統(tǒng)”。為每個模塊完成的功能進(jìn)行具體描述，把功能描述轉(zhuǎn)變?yōu)榫_的、結(jié)構(gòu)化的過程描述。結(jié)束標(biāo)準(zhǔn)：設(shè)計出程序的詳細(xì)規(guī)格說明。342、軟件開發(fā)時期系統(tǒng)實現(xiàn)編碼基本任務(wù)：把每個模塊的控制結(jié)構(gòu)轉(zhuǎn)換成計算機(jī)可接受的程序代碼。寫出的程序應(yīng)是結(jié)構(gòu)好，清晰易讀，并且與設(shè)計一致。結(jié)束標(biāo)準(zhǔn)：以某種程序設(shè)計語言表示的源程序清單。測試基本任務(wù)：通過各種類型的測試使軟件達(dá)到預(yù)定的要求。結(jié)束標(biāo)準(zhǔn)：軟件合格，能交付用戶使用。353、軟件維護(hù)時期基本任務(wù)：通過各種必要的維護(hù)活動使系統(tǒng)持久地滿足用戶需要。364、技術(shù)審查和管理復(fù)審 技術(shù)審查是從技術(shù)角度進(jìn)行的審查，是保證軟件質(zhì)量和降低軟件成本的重要措施。在每一階段

12、結(jié)束前進(jìn)行，對于持續(xù)時間很長的開發(fā)階段，在階段中間還要根據(jù)需要進(jìn)行多次正式的或非正式的技術(shù)審查。技術(shù)審查通常由技術(shù)專家組成的審查小組來承擔(dān)審查工作。審查過程包括：準(zhǔn)備和閱讀被審文檔、開審查會、返工、復(fù)查。 管理復(fù)審的主要任務(wù)是在軟件生存周期的每個重要的里程碑，對工程項目的成本、實際花費的經(jīng)費、投資回收的前景、項目的進(jìn)度等經(jīng)濟(jì)因素從管理角度進(jìn)行審查。從管理角度對軟件開發(fā)工程進(jìn)行復(fù)審，是對工程進(jìn)行管理和控制的主要手段，對發(fā)現(xiàn)的問題可以及時采取措施加以解決，必要時甚至可以取消開發(fā)工程以避免更大的損失。37名詞解釋軟件工作產(chǎn)品在CMM中，它是軟件開發(fā)活動中的人工制品，如需求說明書、概要設(shè)計說明書、詳細(xì)

13、設(shè)計說明書、源程序、測試報告、用戶手冊，也包括軟件管理文檔，如軟件開發(fā)計劃、軟件質(zhì)量保證計劃、各種評審報告、里程碑報告、變更申請表、不符合項跟蹤報告等。軟件產(chǎn)品在CMM中軟件產(chǎn)品是最終用戶使用的軟件。它是軟件工作產(chǎn)品的一部分。基線它是軟件工作產(chǎn)品。它是要經(jīng)內(nèi)部和外部評審過的，并且是下一階段工作的基礎(chǔ)，一根基線是一個里程碑或一個檢查點。檢查點它是由時間、計劃、事件驅(qū)動的檢查工作進(jìn)度和質(zhì)量的一個記號，一個檢查點不一定是基線或里程碑。里程碑它是一個記號，只需經(jīng)過內(nèi)部評審。它是一個檢查點，但不一定是基線。評審是對軟件工作產(chǎn)品質(zhì)量的一次開會或匯簽活動。審計是復(fù)查評審活動程序的合法性，是否按程序與規(guī)范進(jìn)行

14、。顧客客戶用戶客戶是顧客的一部分，顧客包括潛在的客戶。用戶是軟件產(chǎn)品的最終使用者，用戶是客戶的一部分。現(xiàn)有系統(tǒng)目標(biāo)系統(tǒng)現(xiàn)有系統(tǒng)是用戶當(dāng)前正在使用的系統(tǒng)（可能是手工系統(tǒng)）；目標(biāo)系統(tǒng)是將要實現(xiàn)的系統(tǒng)。Capability Maturity Model forsoftware385、瀑布模型特點是一個理想化過程。會掩飾項目中真正的風(fēng)險，當(dāng)你太晚發(fā)現(xiàn)它們時已無濟(jì)于事。 過程逆轉(zhuǎn)性很差，因為上游的錯誤會在下游進(jìn)行發(fā)散性傳播。所以逆轉(zhuǎn)會造成很大損失。缺乏靈活性;特別是無法解決軟件需求不明確或不準(zhǔn)確的問題后期錯誤，修正代價高 。純瀑布模型的缺點是在項目開始的時候，在設(shè)計工作完成前和代碼寫出來前，很難充分描述

15、需求。瀑布模型最主要的問題是缺乏靈活性。必須在項目開始前說明全部需求。但這恰恰是非常困難的。6、瀑布模型適用場合當(dāng)有一個穩(wěn)定的產(chǎn)品定義和很容易被理解的技術(shù)解決方案時，純瀑布模型特別合適當(dāng)你對一個定義得很好的版本進(jìn)行維護(hù)或?qū)⒁粋€產(chǎn)品移植到一個新的平臺上，瀑布模型也特別合適。純瀑布模型能夠降低管理費用，因為你可以預(yù)先完成所有計劃。對于那些容易理解但很復(fù)雜的項目，采用純瀑布模型比較合適，因為可以用順序方法處理問題。在質(zhì)量需求高于成本需求和進(jìn)度需求的時候，它尤為出色。當(dāng)開發(fā)隊伍的技術(shù)力量比較弱或者缺乏經(jīng)驗時，瀑布模型更為適合。39407、瀑布模型變種：V型模型該方法是對瀑布模型的修正，強(qiáng)調(diào)了驗證活動4

16、18、瀑布模型變種：生魚片模型把階段重疊起來的瀑布模型起源于日本硬件開發(fā)模型（富士通施樂）軟件概念需求分析架構(gòu)設(shè)計詳細(xì)設(shè)計編碼和調(diào)試系統(tǒng)測試428、瀑布模型變種：生魚片模型傳統(tǒng)的瀑布模型強(qiáng)調(diào)階段之間最小的重疊，而生魚片模型強(qiáng)調(diào)大幅度的重疊，即在需求分析完成之前就可以進(jìn)行架構(gòu)設(shè)計和部分詳細(xì)設(shè)計純瀑布模型強(qiáng)調(diào)在任意兩個階段交接時，文檔從一個團(tuán)隊交給另一個完全隔離的團(tuán)隊，但是如果一個團(tuán)隊完成各個階段任務(wù)時，可以沒有那么多文檔。問題：缺點是什么？生魚片模型因為階段重疊，因而里程碑不明確，很難有效地進(jìn)行過程跟蹤和控制。439、瀑布模型變種：具有子項目的瀑布模型純瀑布模型的一個問題是必須完成全部的架構(gòu)設(shè)計

17、后才能進(jìn)行詳細(xì)設(shè)計，但是，整個系統(tǒng)中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為為子項目。問題：該模型有何問題？這種方法的主要風(fēng)險是相關(guān)性無法預(yù)料。4410、瀑布模型變種：能夠降低風(fēng)險的瀑布模型純瀑布模型要求在開始架構(gòu)設(shè)計前，必須將用戶的所有需求都搞清楚，但是實際中是很困難的?？山档惋L(fēng)險的瀑布模型是在頂端，即需求分析和架構(gòu)設(shè)計階段引入螺旋以便降低風(fēng)險。在該螺旋中，先開發(fā)一個用戶界面原型，采用系統(tǒng)情節(jié)串聯(lián)圖版（system storyboarding）引導(dǎo)用戶提出需求，記錄用戶與系統(tǒng)的交互操作方式，或者采用其它需求獲取方法。45演化模型需求的采集與細(xì)化客戶評價原型快速設(shè)計建造原型

18、加工原型產(chǎn)生樣品停止開始先開發(fā)一個“原型”軟件，完成部分主要功能，展示給用戶并征求意見，然后逐步完善，最終獲得滿意的軟件產(chǎn)品。46三、螺旋模型螺旋模型將瀑布模型與演化模型結(jié)合起來，并且加入兩種模型均忽略了的風(fēng)險分析。螺旋模型沿著螺線旋轉(zhuǎn)，自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出更完善的一個新版本。 制定計劃 確定軟件目標(biāo)，選定實施方案，弄清項目開發(fā)的限制條件；風(fēng)險分析 分析所選方案，考慮如何識別和消除風(fēng)險；實施工程 實施軟件開發(fā)客戶評估 評價開發(fā)，提出修正建議。47三、螺旋模型螺旋模型是一種風(fēng)險驅(qū)動的模型。螺旋模型需要有相當(dāng)豐富的風(fēng)險評估經(jīng)驗和專門知識。2022/7/1948ReviewCommitment

19、PartitionRisk analy-sisPrototype 1Simulations, models, benchmarksRequirements plan, life-cycle planConcept of operationPrototype 2Risk analysisSoftware requirementsRequirements validationDevelop-ment planRisk analysisPrototype 3Software product designDesign validation and verificationIntegration and

20、 test planRisk analysisOperational prototypeDetailed designUnit testCodeIntegration and testAcceptance testImplementationPlan next phasesDevelop, verify next-level productDetermine objectives, alternatives, constrainsEvaluate alternatives, identify, resolve risksCumulative costProgress through steps

21、The spiral model49螺旋模型決定目標(biāo)、方案和限制評價方案、識別風(fēng)險、弱化風(fēng)險開發(fā)、驗證、下一級產(chǎn)品計劃下一階段集成測試50四、增量模型123491011125678需求分析設(shè)計編碼測試第1塊第1次集成第2次集成第3次集成第N次集成第4次集成第1塊第1塊第1塊第1塊第N塊第4塊第3塊第2塊第2塊第2塊第2塊第3塊第3塊第4塊51四、增量模型遵循遞增方式進(jìn)行軟件開發(fā)。開發(fā)一部分，向用戶展示一部分。增量模型是一種非整體開發(fā)的模型。適用條件：1）使用面向?qū)ο笳Z言或第四代語言；2）需求可能發(fā)生變化，客戶接受分階段交付；3）分析設(shè)計人員對應(yīng)用領(lǐng)域不熟悉，難以一步到位；4）項目風(fēng)險高；52五

22、、原型模型-概念快速原型模型：先開發(fā)一個“原型”軟件，完成主要功能，展示給用戶并征求意見，然后逐步完善。探索型原型：用于需求分析階段；實驗型原型：用于設(shè)計階段；演化型原型：軟件開發(fā)全過程，及早向用戶提交一個原型系統(tǒng)。原型運(yùn)用方式：拋棄策略和附加策略。53五、原型開發(fā)過程-開發(fā)步驟原型開發(fā)步驟:快速分析：分析人員與用戶配合，迅速確定系統(tǒng)的基本要求。要根據(jù)原型所要體現(xiàn)的特征，描述基本需求。關(guān)鍵是要注意分析描述內(nèi)容的選取。構(gòu)造原型：在軟件工具支持下盡快實現(xiàn)一個可運(yùn)行的系統(tǒng)。運(yùn)行原型：是發(fā)現(xiàn)問題、消除誤解、開發(fā)者與用戶充分協(xié)調(diào)的一個步驟。評價原型：評價原型的特性，糾正誤解與錯誤，增添新要求或提出要求變

23、動，提出全面的修改意見。修改：原型開發(fā)的循環(huán)。54五、原型模型的評價原型的優(yōu)點：可及早為用戶提供有用的產(chǎn)品。可及早發(fā)現(xiàn)問題，隨時糾正錯誤。減少技術(shù)、應(yīng)用風(fēng)險，縮短開發(fā)時間，減少費用。促使用戶主動參與開發(fā)活動，促進(jìn)各類人員的協(xié)調(diào)，減少誤解，適應(yīng)需求的變化，能有效提高系統(tǒng)質(zhì)量。原型存在的問題：缺乏豐富而強(qiáng)有力的軟件工具和開發(fā)環(huán)境。缺乏有效的管理機(jī)制，還未建立起自己的開發(fā)標(biāo)準(zhǔn)。對設(shè)計人員水平和開發(fā)環(huán)境要求較高。在多次重復(fù)改變原型的過程中，程序員會感到厭煩。系統(tǒng)的易變性對測試有一定影響，難于做到徹底測試，更新文檔較為困難。2022/7/1955五、原型模型-快速原型法快速原型法(Prototyping

24、)適用于用戶驅(qū)動的系統(tǒng)（即需求模糊或隨時間變化的系統(tǒng)）PrototypeFeedbackModification56快速原型模型需求分析需求說明設(shè)計說明源程序軟件產(chǎn)品設(shè)計編碼測試維護(hù)快速分析需求說明原型修改意見修改類型構(gòu)造原型運(yùn)行原型評價原型停止修改修改說明修改原型57六、噴泉模型主要用于采用面向?qū)ο蠹夹g(shù)的項目噴泉體現(xiàn)迭代和無間隙的特征軟件的某些部分常常被重復(fù)工作多次，相關(guān)對象在每次迭代中隨之加入漸進(jìn)的軟件成分在分析、設(shè)計、實現(xiàn)等各項活動之間無明顯邊界58六、噴泉模型體現(xiàn)了迭代和無間隙的特性。系統(tǒng)某個部分常常重復(fù)工作多次，相關(guān)對象在每次迭代中隨之加入演進(jìn)的軟件成分。無間隙是指在各項開發(fā)活動，即

25、分析、設(shè)計和編碼之間不存在明顯的邊界。噴泉模型是對象驅(qū)動的過程。 59需求階段分析階段設(shè)計階段編程階段集成與測試階段維護(hù)與演進(jìn)階段60七、迭代模型（RUP模型）Rational Unified Process初始精化構(gòu)建移交9個核心流程對初學(xué)者來說，使用比較困難61八、智能模型智能模型是基于知識的軟件開發(fā)模型，它把瀑布模型和專家系統(tǒng)綜合在一起。該模型在各個開發(fā)階段都利用了相應(yīng)的專家系統(tǒng)來幫助軟件人員完成開發(fā)工作。為此，建立了各個階段的知識庫，將模型、相應(yīng)領(lǐng)域知識和軟件工程知識分別存入數(shù)據(jù)庫。以軟件工程知識為基礎(chǔ)的生成規(guī)則構(gòu)成的專家系統(tǒng)與包含應(yīng)用領(lǐng)域知識規(guī)則的其他專家系統(tǒng)相結(jié)合，構(gòu)成該應(yīng)用領(lǐng)域的

26、開發(fā)系統(tǒng)。 62用戶要求需求分析概要設(shè)計詳細(xì)設(shè)計程序編碼測試維護(hù)支持需求 分析的專家系統(tǒng)支持軟件 設(shè)計的專家系統(tǒng) 支持測試的專家系統(tǒng) 支持維護(hù)的專家系統(tǒng)6364九、軟件生存周期模型的剪裁在一個成熟的IT企業(yè)或軟件組織內(nèi)部，通常要根據(jù)各種軟件開發(fā)模型的特點，結(jié)合本單位的開發(fā)經(jīng)驗和行業(yè)特點的具體實際，還需要定制適合本單位的“生存周期模型裁剪指南”，有針對性地對選定的軟件開發(fā)模型中定義的生存周期，進(jìn)行適當(dāng)剪裁，使它完全適合于本單位的需求。所謂裁剪，就是對原模型中定義的內(nèi)容進(jìn)行增、改、刪，去掉對本單位不適用的內(nèi)容，同時進(jìn)一步細(xì)化，從而構(gòu)成了完全適合本單位的“軟件生存周期模型裁剪指南”。該指南在軟件組織

27、內(nèi)部，專供高層經(jīng)理和項目經(jīng)理在軟件策劃中選取軟件開發(fā)模型時使用。 65在軟件開發(fā)過程中必須遵循的軟件工程原則有：抽象與自頂向下、逐層細(xì)化信息隱蔽和數(shù)據(jù)封裝模塊化局部化確定性一致性和標(biāo)準(zhǔn)化完備性和可驗證性 十、軟件工程原則66軟件工程的基本原理有：按軟件生存期分階段制定計劃并認(rèn)真實施；堅持進(jìn)行階段評審；堅持嚴(yán)格的產(chǎn)品控制；使用現(xiàn)代程序設(shè)計技術(shù)；明確責(zé)任，使得工作結(jié)果能夠得到清楚的審查；用人少而精；不斷改進(jìn)開發(fā)過程。十一、軟件工程的基本原理67案例分析整定軟件采用了以原型模型為主的軟件開發(fā)模型。故障分析是電力系統(tǒng)中非?；镜倪\(yùn)算，算法比較成熟，軟件用戶對此模塊的功能也較熟悉，需求變動相對較小，因而

28、本功能模塊可以采用瀑布模型。但由于我們已有故障分析程序，只需對該程序的接口、部分功能算法進(jìn)行修改和調(diào)整，所以采用原型模型較為合適。軟件開發(fā)階段中重點關(guān)注需求分析階段，弄清楚已有程序與用戶需求間的差距。圖形建模在建模范圍方面基本明確，但在具體內(nèi)容方面仍有不確定性，原因是用戶對此功能模塊的想法還不夠清晰，通常用“待基本的出來后再討論”來回答一些細(xì)節(jié)問題。此外，我們有以前其他項目的圖形建模軟件基礎(chǔ)，所以本模塊采用了演化型原型模型，采用附加策略。先在以前圖形建模的軟件基礎(chǔ)上去除一些不需要的內(nèi)容和添加新的內(nèi)容，向用戶提交初步的原型系統(tǒng)，然后再根據(jù)用戶的意見進(jìn)行修改，在反復(fù)多次中才達(dá)成需求的徹底清晰，此時

29、本模塊軟件也可以基本開發(fā)完成。整定計算是專業(yè)性很強(qiáng)的內(nèi)容，通常需要較多的整定人員工作經(jīng)驗，而整定經(jīng)驗的獲得往往無法一次完成，因此開發(fā)方需要經(jīng)常與用戶交流溝通。此外，整定計算模塊用戶最關(guān)心的是軟件的可用性，即計算過程是否方便、透明，計算結(jié)果是否合理。因此，整定計算也采用了原型模型，以某種原理的保護(hù)為例反復(fù)設(shè)計與修改整定的流程，直到滿足用戶的可用性和實用性為止，其他原理的保護(hù)整定則以此為模板進(jìn)行開發(fā)。 68總結(jié)掌握：軟件生存期各個階段的基本任務(wù)；軟件生存期模型。了解：軟件生存期的各種模型及特點。69第三講軟件要求定義70學(xué)習(xí)內(nèi)容可行性研究項目開發(fā)計劃軟件需求分析71項目來源合同：為別人做；立項：為

30、自己做；失敗：無盈利賠錢聲譽(yù)影響官司失?。罕M賠錢公司倒閉東山再起難！學(xué)到的遠(yuǎn)比失去的多！ 72可行性研究（ Feasibility Study） 可行性研究的目的就是用最小的代價在盡可能短的時間內(nèi)確定該軟件項目是否能夠開發(fā)，是否值得開發(fā)，最后給決策者提供做與不做的依據(jù)。 可行性研究實質(zhì)上是要進(jìn)行一次簡化、壓縮了的需求分析和設(shè)計過程，要在較高層次上以抽象的方式進(jìn)行需求分析和設(shè)計過程。73可行性研究的任務(wù) 首先需要進(jìn)行概要的分析研究，初步確定項目的規(guī)模和目標(biāo)，確定項目的約束和限制。 然后進(jìn)行簡要的需求分析，抽象出該項目的邏輯結(jié)構(gòu)，建立邏輯模型。 最后從邏輯模型出發(fā)，經(jīng)過壓縮的設(shè)計，探索出若干種可供

31、選擇的主要解決辦法，對每種解決方法都要從以下三方面研究它的可行性。技術(shù)可行性經(jīng)濟(jì)可行性社會可行性74技術(shù)可行性在現(xiàn)有資源條件下，項目能否實現(xiàn)，風(fēng)險有多大（技術(shù)、資源是否成熟）。社會可行性是否存在侵權(quán)、軟件操作方式是否適合用戶所在組織、現(xiàn)有管理制度、人員素質(zhì)是否可行？75經(jīng)濟(jì)可行性（成本效益分析） 成本效益分析首先是估算將要開發(fā)的系統(tǒng)的開發(fā)成本，然后與可能取得的效益進(jìn)行比較和權(quán)衡。效益分有形效益和無形效益。有形效益可以用貨幣的時間價值、投資回收期和純收入等指標(biāo)進(jìn)行度量；無形效益主要從性質(zhì)上、心理上進(jìn)行衡量，很難直接進(jìn)行量的比較。貨幣的時間價值：通常用利率表示。 F=P(1+n i) 不計復(fù)利投資

32、回收期：就是使累計的經(jīng)濟(jì)效益等于最初的投資費用所需的時間。純收入：就是在整個生存周期之內(nèi)的累計經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差。76提示不是解決問題，而是確定是否可解值得解所以不要花過多精力，占總成本的 5 10 %例：實踐性大作業(yè) 3 方面考慮：技術(shù)上- 23 學(xué)生, 7 周, 電腦, 開發(fā)經(jīng)驗 ，決心，風(fēng)險（影響其它課程）. 社會上- 產(chǎn)品有沒有人用 經(jīng)濟(jì)上 - 預(yù)算, 盈利, .77可行性研究的具體步驟1、確定項目規(guī)模和目標(biāo)，明確限制和約束。我們認(rèn)為用戶要的 用戶要的2、研究老系統(tǒng) 解決老系統(tǒng)問題老系統(tǒng)功能新增功能注：注意了解與其它系統(tǒng)的接口。 新系統(tǒng)效益 老系統(tǒng)效益 78可行性研究的

33、具體步驟3、導(dǎo)出高層邏輯模型(conceptual design)抽象實現(xiàn)改進(jìn)老系統(tǒng)模型新模型新系統(tǒng)應(yīng)該告訴用戶“What”而不是“How”79系統(tǒng)流程圖（事務(wù)圖）高層邏輯模型80可行性研究的具體步驟 3、邏輯模型4、復(fù)查和重新定義 1、復(fù)查定義 注：此時合同未簽，應(yīng)考慮成本，不宜反復(fù)太多次。5、導(dǎo)出和評價多種解法進(jìn)度表經(jīng)濟(jì)上合算技術(shù)上可行操作上可行技術(shù)上不可行用戶不可能操作不合算81可行性研究的具體步驟6、推薦行動方針Yes or No?NoYesWhy?Which one is the best?Why? (cost / benefit)8、審查、存檔7、編寫可行性報告（開發(fā)計劃） 任務(wù)分

34、解，確定負(fù)責(zé)人 大致進(jìn)度規(guī)劃 財務(wù)預(yù)算 風(fēng)險分析及對策粗略82文檔：可行性報告 參考GB856788中的可行性研究報告，進(jìn)行適當(dāng)裁剪。83項目開發(fā)計劃 是對開發(fā)項目的費用、時間、進(jìn)度、人員組織、硬件設(shè)備的配置、軟件開發(fā)環(huán)境和運(yùn)行環(huán)境的配置等進(jìn)行說明和規(guī)劃。 是項目管理人員對項目進(jìn)行管理的依據(jù)，據(jù)此對項目的費用、進(jìn)度和資源進(jìn)行控制和管理。工具：Project85注意事項標(biāo)書 ：我國對軟件成本認(rèn)識不足人月不能互換：需求的變更、人員的流動、環(huán)境的變化；困難：就是缺乏數(shù)據(jù)估計，導(dǎo)致估計不科學(xué)；估算項目復(fù)雜度（熟悉程度）、規(guī)模 86軟件需求分析：“做什么？” 需求分析的過程是開發(fā)人員與用戶共同協(xié)商，明確

35、系統(tǒng)的全部功能、性能以及運(yùn)行規(guī)格，并且使用軟件開發(fā)人員和用戶都能理解的語言準(zhǔn)確地表達(dá)出來，即完成需求規(guī)格說明的過程。87軟件需求重要性例子 “喂，是Jack嗎？我是人力資源部的Tom,我們在使用你編寫的職員系統(tǒng)時遇到一個問題，一個職員想把她的名字改成Sparkle Starlight,而系統(tǒng)不允許，你能幫幫忙嗎？”“她嫁給了一個姓Starlight的人嗎？”Jack問道。“不，她沒有結(jié)婚，而僅僅是要更改她的名字，”Tom回答，“就是這問題，好象我們只能在婚姻狀況改變時才能更改姓名?！薄爱?dāng)然這樣，我從沒想到誰會莫名其妙地更改姓名，我也不記得你曾告訴我系統(tǒng)需要處理這樣的事情?！盝ack說。 Tom

36、說：“我想你當(dāng)然知道每個人只要愿意都可以隨時合法更改其姓名。但不管怎樣，你在本周五之前解決這問題，否則Sparkle不能支付她的帳單。”“這不是我的錯！我現(xiàn)在正忙著做一個新的系統(tǒng)，還要做一些別的需求變更請求。很抱歉，只能下周才能修改?！?8故事帶給我們的啟示 影響：作為客戶，很惱火，因為軟件系統(tǒng)不能進(jìn)行一項基本的操作。哪怕開發(fā)者給其解決了，也不會感謝他。作為開發(fā)者，也很煩人，迫使你增加了當(dāng)前的工作，又要你優(yōu)先處理。原因：由于收集、編寫、協(xié)商、修改需求過程的手續(xù)或方法失誤帶來的。這里是非正式信息的收集、未確定或不明確的功能、未發(fā)現(xiàn)或未經(jīng)交流的假設(shè)、不完善的需求文檔，以及突發(fā)的需求變更過程所造成的

37、。解決辦法：重視需求分析，派經(jīng)驗豐富的人員做，最大程度的減少類似情況發(fā)生。89定值整定原則1：按與相鄰接地距離保護(hù)配合整定；原則2：按相鄰零序電流保護(hù)配合整定；1231與2配；1與3配；方案1：原則相鄰線方案2：相鄰線原則90需求分析的特點老問題：問題的復(fù)雜性交流障礙（講究技巧和原則）不完備性和不一致性需求易變性（動態(tài)性）派經(jīng)驗豐富的人去干！系統(tǒng)分析員91軟件需求的任務(wù)理解、分解、表達(dá)、評審whf:劃分系統(tǒng)所有1.問題識別：雙方確定問題的綜合需求。功能需求：系統(tǒng)必須做什么？ 性能需求：做得怎樣？例：response time , memory , back-up memory , 環(huán)境需求：運(yùn)

38、行環(huán)境、軟硬件配置等。用戶界面需求可靠性、安全性、保密性、可移植性和可維護(hù)性等方面的需求。將來可能提出的要求共同理解！92軟件需求的任務(wù)2.分析與綜合:導(dǎo)出軟件的邏輯模型。對獲取的需求進(jìn)行一致性的分析檢查，在分析、綜合中逐步細(xì)化軟件功能，劃分成各個子功能。也對數(shù)據(jù)域進(jìn)行分解，分配到各個子功能上，并用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。93軟件需求的任務(wù)3.編寫文檔：編寫需求說明書 編寫初步用戶使用手冊編寫確認(rèn)測試計劃 修改完善項目開發(fā)計劃94需求文檔用戶需求報告需求規(guī)格說明書對外的，驗收依據(jù)對內(nèi)的，設(shè)計依據(jù)是合同的產(chǎn)物是立項建議書的產(chǎn)物由用戶需求報告可產(chǎn)生需求規(guī)格說明書當(dāng)前系統(tǒng)，目標(biāo)系統(tǒng)目

39、標(biāo)系統(tǒng)（數(shù)據(jù)字典，算法分析）95軟件需求的任務(wù)驗證需求的一致性驗證需求的完整性驗證需求的現(xiàn)實性驗證需求的有效性方法： 人工審查 開發(fā)原型系統(tǒng)探索型使用軟件工具 完整性、一致性基線4.技術(shù)審查和管理復(fù)審96需求分析的方法結(jié)構(gòu)化分析方法：由數(shù)據(jù)流和數(shù)據(jù)字典構(gòu)成，適于數(shù)據(jù)處理領(lǐng)域問題。但該方法的一個難點是確定數(shù)據(jù)流之間的變換，而且數(shù)據(jù)字典的規(guī)模也是一個問題，對數(shù)據(jù)結(jié)構(gòu)的強(qiáng)調(diào)很少。功能分解法：系統(tǒng)功能子功能功能接口。過程抽象觀點，很難與軟件設(shè)計明確分離?；c放在功能上，不穩(wěn)定，難以適用需求的變化。97需求分析的方法信息建模方法：從數(shù)據(jù)角度來對現(xiàn)實世界建模?；竟ぞ呤荅-R圖，數(shù)據(jù)不封閉，每個實體和它的

40、屬性的處理需求不是組合在同一實體中，沒有繼承性和消息傳遞機(jī)制來支持模型。是面向?qū)ο蠓治龅幕A(chǔ)。面向?qū)ο蟮姆治觯翰捎昧藢嶓w、關(guān)系和屬性等信息模型分析中的概念，同時采用了封閉、類結(jié)構(gòu)和繼承性等面向?qū)ο蟪绦蛟O(shè)計語言中的概念。98ER模型（Entity-Relationship Approach）實體：客觀世界中存在且可相互區(qū)分的事物。用矩形框代表。聯(lián)系：事物間是有聯(lián)系的。(1:1、1:N、M:N) 用連接相關(guān)實體的菱形框表示。屬性：實體或聯(lián)系所具有的性質(zhì)。 用橢圓形或圓角矩形表示。教師學(xué)生課程教學(xué)學(xué)號職稱成績學(xué)分1NNM99注意事項在需求分析時要注意用戶對軟件開發(fā)的了解程度。避免造成兩種極端認(rèn)識。

41、需求的變動或新增是一個極為普遍的問題，既然普遍，所以軟件開發(fā)人員不僅應(yīng)該在心理上接受這種變動，還應(yīng)該在需求分析時積極的發(fā)掘需求。需求人員與用戶廣泛交流，從深度和廣度挖掘可能的需求，并應(yīng)形成規(guī)范的需求文檔，經(jīng)用戶確認(rèn)。如果為寫文檔而寫文檔，不進(jìn)行及時更新，甚至準(zhǔn)備在軟件開發(fā)完成后再補(bǔ)文檔，這是絕對錯誤的觀點。 100可能錯誤沒有足夠用戶從參與（類型、數(shù)量）開發(fā)方與用戶溝通可能處于劣勢不要錦上添花，畫蛇添足不要寫的過于簡練，過于模糊；計劃需求的時間少了，導(dǎo)致需求不完整另外，要注意：需求在簽約前要與決策者溝通好；到競爭對手那兒找不足不要被過細(xì)的不成熟的細(xì)節(jié)影響記下不明確的需求，約定期限明確，否則易遺

42、漏101總結(jié)熟練掌握：軟件需求分析的任務(wù)及分析的方法 掌握：可行性研究的任務(wù)。了解：其余作一般了解。102作業(yè)一人組：交實驗三；二人組：交實驗三、實驗四三人組：交實驗一/二、實驗三、實驗四四人組：交實驗一/二、實驗三、實驗四、實驗五103104結(jié)構(gòu)化方法105學(xué)習(xí)內(nèi)容結(jié)構(gòu)化方法概述結(jié)構(gòu)化分析數(shù)據(jù)流圖數(shù)據(jù)字典加工邏輯的描述結(jié)構(gòu)化設(shè)計106一.結(jié)構(gòu)化方法概述 它包括結(jié)構(gòu)化分析（Structured Analysis）、結(jié)構(gòu)化設(shè)計（ Structured Design）和結(jié)構(gòu)化程序設(shè)計（ Structured Programming）三部分組成。 結(jié)構(gòu)化方法的基本指導(dǎo)思想是自頂向下，逐步求精，它的基

43、本原則是抽象與分解。107結(jié)構(gòu)化方法特點成功率較高，發(fā)展較為成熟；簡單、易掌握，適應(yīng)于瀑布模型；特別適合于數(shù)據(jù)處理領(lǐng)域中的應(yīng)用，對規(guī)模大的項目，特別復(fù)雜的應(yīng)用不太適應(yīng)。難于解決軟件重用問題，難于適應(yīng)需求的變化。108二、結(jié)構(gòu)化分析策略：它根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解描繪出滿足功能要求的軟件模型。 X1231.11.21.33.13.23.32.12.2頂層：整個系統(tǒng)逐層添加細(xì)節(jié)109結(jié)構(gòu)化分析步驟建立當(dāng)前系統(tǒng)的物理模型（系統(tǒng)流程圖，怎么做）抽象出當(dāng)前系統(tǒng)的邏輯模型。（做什么）建立目標(biāo)系統(tǒng)的邏輯模型。作進(jìn)一步補(bǔ)充和優(yōu)化。110描述工具數(shù)據(jù)流圖 ：描速系統(tǒng)的分解。數(shù)據(jù)詞典：定

44、義數(shù)據(jù)流圖中的數(shù)據(jù)和加工。描述加工邏輯的結(jié)構(gòu)化語言、判定表、判定樹等工具：詳細(xì)描述數(shù)據(jù)流圖中不能被再分解的每一個基本加工的處理邏輯 。111數(shù)據(jù)流圖 數(shù)據(jù)流圖（Data flow Diagram，簡稱DFD）是表示系統(tǒng)邏輯模型的一種工具，以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中的流動和處理過程。由于只反映系統(tǒng)必須完成的邏輯功能，所以是一種功能模型。112數(shù)據(jù)流圖基本圖形符號數(shù)據(jù)源點和終點：系統(tǒng)的外部實體。一般只出現(xiàn)在頂層圖中。為了避免在數(shù)據(jù)流圖上出現(xiàn)數(shù)據(jù)流的線條交叉，同一個外部實體允許在一張圖上出現(xiàn)多次。數(shù)據(jù)源/終點名稱源/終點名稱源/終點名稱或113數(shù)據(jù)流圖基本圖形符號加工 ：對數(shù)據(jù)進(jìn)行處理。加工名一般

45、用一個動詞和一個作賓語的名詞所組成。編號加工名或編號加工名114數(shù)據(jù)流圖基本圖形符號數(shù)據(jù)流： 數(shù)據(jù)及其流向，通常由一組數(shù)據(jù)項組成。有時數(shù)據(jù)流很難用簡單而適當(dāng)?shù)脑~表達(dá)，這時可用概括性的語句來表達(dá)，一般用名詞或名詞短語表示。數(shù)據(jù)流名問詢訂貨單顧客支票信息顧客顧客事務(wù)處理顧客事務(wù)處理顧客事務(wù)內(nèi)容115數(shù)據(jù)流圖基本圖形符號數(shù)據(jù)存儲：信息的靜態(tài)存儲。它也允許在一張數(shù)據(jù)流圖上重復(fù)出現(xiàn)相同的數(shù)據(jù)存儲，以避免數(shù)據(jù)流的交叉。數(shù)據(jù)名稱或編號數(shù)據(jù)名稱F2 庫存記錄F2 庫存記錄116數(shù)據(jù)流圖的分層方法 描述一個復(fù)雜的系統(tǒng)，不可能一下子引進(jìn)太多的細(xì)節(jié)。否則用一張數(shù)據(jù)流圖畫出所有的數(shù)據(jù)流和加工，則這張圖將是極其龐大而復(fù)

46、雜，因而難以繪制，也難以理解。所以必須用分層的方法將一個流程圖分解成幾個流程圖，來分別表示。117數(shù)據(jù)流圖的分層方法一套分層的數(shù)據(jù)流圖由頂圖、0層圖、中間層和底圖的數(shù)據(jù)流圖所組成。頂圖說明了系統(tǒng)的邊界，即系統(tǒng)的輸入和輸出的數(shù)據(jù)流，頂圖只有一個加工，標(biāo)識被開發(fā)的系統(tǒng)。畫系統(tǒng)內(nèi)部，一般將層號從0開始編號。0層圖分解頂層圖的系統(tǒng)為若干子系統(tǒng)。底圖由一些不必再分解的加工組成，這些加工稱為基本加工。在頂圖和底圖之間是中間層。稱上層圖為下層圖的“父”圖，下層圖稱為上層圖的“子”圖。118子圖P1bd子圖P2cabd父圖（0層圖）cde子圖P3eP1P3P2acP1 .3P1 .2P1 .1P2 .1P2

47、.2P2 .3P3 .3P3 .2P3 .1Pabe源點1終點源點2頂圖119繪制數(shù)據(jù)流圖的幾個問題合理地命名：數(shù)據(jù)流程圖中對每一個元素都要命名，恰當(dāng)?shù)孛兄跀?shù)據(jù)流程圖的理解與閱讀。命名原則：為了避免引起錯覺，為每個元素所取的名字要能反映該元素的整體性內(nèi)容，而不只是它的部分內(nèi)容。每個元素的名字都能有唯一地標(biāo)識該元素。避免用空洞的名字，要具體的含義。如果發(fā)現(xiàn)難以為某個數(shù)據(jù)流或加工命名時，這往往是數(shù)據(jù)流圖分解不當(dāng)?shù)恼髡?，可重新分解?20繪制數(shù)據(jù)流圖的幾個問題編號的設(shè)置子圖的編號是父圖相應(yīng)的加工的編號。子圖中加工編號由子圖號、小數(shù)點與局部號組成。121繪制數(shù)據(jù)流圖的幾個問題父圖與子圖的平衡子圖

48、是詳細(xì)地描述父圖中加工，因而子圖的輸入、輸出數(shù)據(jù)流應(yīng)該同父圖中加工的輸入、輸出數(shù)據(jù)流相一致。訂貨單P提貨單P3P1P2提貨單數(shù)量客戶122繪制數(shù)據(jù)流圖的幾個問題局部數(shù)據(jù)存儲 局部數(shù)據(jù)存儲不是父圖中相應(yīng)加工的外部接口，而只是本圖中某些加工之間的數(shù)據(jù)接口。在子圖中出現(xiàn)的數(shù)據(jù)存貯，可以不出現(xiàn)在父圖中，畫父圖時只需畫出處理邏輯之間的聯(lián)系，不必畫出各個處理邏輯內(nèi)部的細(xì)節(jié)，有助于實現(xiàn)信息隱蔽。acP1 .3P1 .2P1 .1庫存記錄123繪制數(shù)據(jù)流圖的幾個問題加工的分解與分細(xì)的程度為提高數(shù)據(jù)流圖的易理解性，注意合理分解。分得太細(xì)，則使得層次太多；分得太快，則達(dá)不到分層的目的。從管理的層次結(jié)構(gòu)原理來看，一

49、個領(lǐng)導(dǎo)人管理他的下屬一般不超過7人，故在分解一層時不宜超過7個加工。一個加工分解到基本加工為止?；炯庸ぃ耗鼙磉_(dá)系統(tǒng)所有的邏輯功能和必要的數(shù)據(jù)輸入與輸出，這些功能與數(shù)據(jù)的描述能使用戶清楚地理解，并且還能使以后的系統(tǒng)設(shè)計人員看到每一個加工，有一個明確的概念，并據(jù)此能設(shè)計程序模塊實現(xiàn)這些加工。注意子加工的獨立性和勻稱性。124125126數(shù)據(jù)流圖實例以某企業(yè)的銷售管理系統(tǒng)為例，采用SA方法進(jìn)行需求分析，建立功能模型。該企業(yè)銷售管理的描述如下：（1）接受顧客的訂單，檢驗訂單。若庫存有貨，則進(jìn)行供貨處理，即修改庫存，給倉庫開備貨單，并將訂單留底；若庫存量不足，則將缺貨訂單登入缺貨記錄。（2）根據(jù)缺貨記

50、錄進(jìn)行缺貨處理，將缺貨通知單發(fā)給采購部門，以便采購。（3）根據(jù)采購部門發(fā)來的進(jìn)貨通知單處理進(jìn)貨，即修改庫存，并從缺貨記錄中取出缺貨訂單進(jìn)行供貨處理。（4）根據(jù)留底的訂單進(jìn)行銷售統(tǒng)計，打印統(tǒng)計表給經(jīng)理。 127數(shù)據(jù)流圖實例頂層圖1280層圖1291層圖圖1圖21301層圖圖3圖41311層圖圖5修改下面的經(jīng)營處理系統(tǒng)顧客供應(yīng)商訂貨單發(fā)貨單訂貨單發(fā)貨單頂層數(shù)據(jù)流程圖經(jīng)營處理系統(tǒng)經(jīng)理統(tǒng)計表顧客P1銷售P2采購供應(yīng)商F1 配件庫存P3會計付款收據(jù)應(yīng)付款通知收款通知到貨通知訂貨單訂貨單發(fā)貨單發(fā)貨單統(tǒng)計缺貨通知第0層數(shù)據(jù)流程圖經(jīng)理統(tǒng)計表付款收據(jù)付款收據(jù)付款收據(jù)134數(shù)據(jù)流圖的優(yōu)缺點總體概念強(qiáng)，每一層都明確

51、強(qiáng)調(diào)“干什么”，“需要什么”，“給出什么”?？梢苑从吵鰯?shù)據(jù)的流向和處理過程。由于自頂向下分析，容易及早發(fā)現(xiàn)系統(tǒng)各部分的邏輯錯誤，也容易修正。容易與計算機(jī)處理相對照。不直觀，一般都要在作業(yè)流程分析的基礎(chǔ)上加以概括、抽象、修正來得到。如果沒有計算機(jī)系統(tǒng)幫助的話，人工繪制太麻煩，工作量較大。135與其它流程圖的差別與系統(tǒng)流程圖的區(qū)別系統(tǒng)流程圖中不僅有數(shù)據(jù)流，還有物質(zhì)流、資金流。數(shù)據(jù)流程圖僅以數(shù)據(jù)流的形態(tài)來反映一個組織中整個管理業(yè)務(wù)的過程。與程序結(jié)構(gòu)圖的區(qū)別程序結(jié)構(gòu)圖反映模塊之間的控制關(guān)系，以及模塊之間的調(diào)用關(guān)系，而數(shù)據(jù)流圖則不反映控制關(guān)系、調(diào)用關(guān)系、控制流，只畫數(shù)據(jù)流。136與其它流程圖的差別與程序

52、流程圖的區(qū)別程序流程圖中的處理框之間有嚴(yán)格的時間上的順序，也就先執(zhí)行哪個處理框，起始點以及終止點等。而數(shù)據(jù)流程圖只反映數(shù)據(jù)的流向、加工和必要的數(shù)據(jù)存儲，它不反映加工的先后的時間順序。數(shù)據(jù)字典Data Dictionary，簡稱DD數(shù)據(jù)字典是用來定義DFD中各個成分的具體含義的，它以一種準(zhǔn)確的、無二義性的說明方式為系統(tǒng)的分析、設(shè)計及維護(hù)提供了有關(guān)元素的一致的定義和詳細(xì)的描述。它和數(shù)據(jù)流圖共同構(gòu)成了系統(tǒng)的邏輯模型。 數(shù)據(jù)字典的內(nèi)容數(shù)據(jù)流、數(shù)據(jù)存貯、數(shù)據(jù)項、基本加工。數(shù)據(jù)字典的符號符 號含義舉例及說明被定義為與X=a+b表示X由a和b組成。 | 或X=a|b表示X由a或b組成。重復(fù)X=a表示X由0個

53、或多個a組成。m n或 nm重復(fù)X=2a5或X a 52 表示X中最少出現(xiàn)2次a，最多出現(xiàn)5次a，5、2為重復(fù)次數(shù)的上下限。()可選X=(a)表示a可在X中出現(xiàn)，也可不出現(xiàn)?！啊被緮?shù)據(jù)元素X=“a”,表示X是取值為字符a的數(shù)據(jù)元素。 連接符X=1 9，表示X可取1到9中任意一個值。139數(shù)據(jù)流條目 在一個數(shù)據(jù)流圖上，數(shù)據(jù)按數(shù)據(jù)流為單位傳輸。主要內(nèi)容有：數(shù)據(jù)流名稱、別名及簡述。數(shù)據(jù)流的來源：可能是一個外部實體、處理邏輯、數(shù)據(jù)存貯。數(shù)據(jù)流的去處。（同上）數(shù)據(jù)流的組成：一個數(shù)據(jù)流可能包括若干個數(shù)據(jù)結(jié)構(gòu)，若只有一個數(shù)據(jù)結(jié)構(gòu)，就不需要專門定義。數(shù)據(jù)流的流通量：單位時間內(nèi)的傳輸次數(shù)。140數(shù)據(jù)流條目舉例

54、數(shù)據(jù)流的名稱：銷售科發(fā)貨單別名：無簡述：工廠對顧客辦理的發(fā)貨單數(shù)據(jù)流來源：“銷售科”外部實體數(shù)據(jù)流去向：“核對發(fā)貨單”處理邏輯數(shù)據(jù)流組成：發(fā)貨單標(biāo)識+顧客+配件流通量：50份/天141數(shù)據(jù)存儲條目 數(shù)據(jù)存儲是數(shù)據(jù)結(jié)構(gòu)停留或保存的場所。主要內(nèi)容：數(shù)據(jù)存儲的名稱、別名及其簡述。流入、流出的數(shù)據(jù)流：流入的數(shù)據(jù)流指出其來源，流出的數(shù)據(jù)流指出其去向。數(shù)據(jù)存儲的組成：指它所包含的數(shù)據(jù)項或數(shù)據(jù)結(jié)構(gòu)。組織方式、查詢要求等。數(shù)據(jù)存儲條目舉例數(shù)據(jù)存儲名稱：銷售歷史別名：無簡述：公司從月初到目前為止所有配件的銷售量。流入的數(shù)據(jù)流：“顧客的發(fā)貨單”，來源是“產(chǎn)生發(fā)貨單”處理邏輯。流出的數(shù)據(jù)流：“銷售量”，去向是“產(chǎn)生

55、銷售報表”處理邏輯。數(shù)據(jù)存貯的組成：配件編號+日期+銷售量。組織方式：以配件編號為關(guān)鍵字建立索引。查詢要求：能立即查詢。143數(shù)據(jù)項條目 數(shù)據(jù)項也稱數(shù)據(jù)元素，是“不可再分”的數(shù)據(jù)單位，是數(shù)據(jù)的最小組成單位。主要內(nèi)容有：數(shù)據(jù)項名稱、別名及簡述：給數(shù)據(jù)項取名時，按“顧名思義”的原則，反映該數(shù)據(jù)項的含義，易于他人理解、記憶。數(shù)據(jù)項的類型數(shù)據(jù)項的長度：指數(shù)據(jù)項所包含的字符或數(shù)字的位數(shù)。取值的范圍和取值的含義144數(shù)據(jù)項條目舉例數(shù)據(jù)項名稱：貨物編號別名：G_No，Goods_No簡述：本公司的所有貨物的編號。類型：字符串長度：10取值/含義：第一位：進(jìn)口/國產(chǎn)24位：類別57位：規(guī)格810：品名編號加工

56、條目用來說明DFD中基本加工的處理邏輯的。加工名；編號；簡述：對處理邏輯的簡明描述，其目的是使人了解這個處理邏輯是做什么用的。激發(fā)條件；優(yōu)先級；輸入、輸出；加工邏輯：描述該加工“做什么”，即實現(xiàn)加工的策略，而不是實現(xiàn)加工的細(xì)節(jié)，描述如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則。常用的描述方法：結(jié)構(gòu)化語言、判定表及判定樹。146加工條目舉例加工名：確定能否供貨編號：1.2簡述：激發(fā)條件：接受到合格訂單時優(yōu)先級：普通輸入：合格訂單輸出：可供貨訂單、缺貨訂單加工邏輯：根據(jù)庫存記錄IF 訂單項目的數(shù)量該項目庫存量的臨界值THEN 可供貨處理ELSE 此訂單缺貨，登記，待進(jìn)貨后再處理ENDIF147加工邏

57、輯的描述結(jié)構(gòu)化語言 結(jié)構(gòu)化語言是在自然語言基礎(chǔ)上加了一些限定，使用有限的詞匯和語句來描述加工邏輯，其結(jié)構(gòu)分內(nèi)外二層。外層用來描述控制結(jié)構(gòu)，采用順序、選擇、重復(fù)三種基本結(jié)構(gòu)。內(nèi)層一般采用祈使語句的自然語言短語。使用數(shù)據(jù)字典中的名詞和有限的自定義詞，動詞含義要具體。還可使用一些簡單的算術(shù)運(yùn)算和邏輯運(yùn)算符號。148結(jié)構(gòu)化語言示例IF 顧客訂額1000IF 顧客信譽(yù)好訂單設(shè)“優(yōu)先”標(biāo)志ELSEIF 顧客是老顧客訂單設(shè)“優(yōu)先”標(biāo)志ELSE訂單設(shè)“正?！睒?biāo)志ENDIFENDIFELSE訂單設(shè)“正常”標(biāo)志ENDIF加工邏輯的描述判定表條件定義條件取值的組合動作定義在各種取值的組合下應(yīng)執(zhí)行的動作判定表1234

58、5678條件顧客訂額1000顧客信譽(yù)好顧客是老顧客處理訂單設(shè)“優(yōu)先”標(biāo)志訂單設(shè)“正常”標(biāo)志150判定表判定表能把什么條件下系統(tǒng)應(yīng)做什么動作準(zhǔn)確地表示出來，同時能發(fā)現(xiàn)需求的不完整性，如某些條件組合下缺少應(yīng)采取的動作。也能發(fā)現(xiàn)冗余的動作，可將條件合并。但判定表不能描述循環(huán)的處理特性，循環(huán)處理還需結(jié)構(gòu)化語言。YNYYNN兩條規(guī)則合并YN-151加工邏輯的描述判定樹 好-優(yōu)先處理1000 顧客信譽(yù) 老顧客-優(yōu)先處理顧客訂額 不好顧客是 新顧客-正常處理 C(p2)then E(p1) E(p2)因為C(p1+p2) C(p1)+ C(p2)，所以 E(p1+p2) E(p1)+ E(p2).定義有效的

59、模塊系統(tǒng)的能力：模塊可分解性模塊可組裝性模塊可理解性模塊連續(xù)性模塊保護(hù)性2、抽象分解：對于一個復(fù)雜的系統(tǒng)，為了將復(fù)雜性降低到可以掌握的程度，可以把大問題分解成若干小問題，然后分別解決。 抽象：分解可以分層進(jìn)行，即先考慮問題最本質(zhì)的屬性，暫把細(xì)節(jié)略去，以后再逐層添加細(xì)節(jié)，直至涉及到最詳細(xì)的內(nèi)容，這種用最本質(zhì)的屬性表示一個子系統(tǒng)的方法就是“抽象”。3、逐步求精求精：是細(xì)化過程，對高抽象級功能陳述說明具體實現(xiàn)細(xì)節(jié)。 求精可以幫助程序員對復(fù)雜問題的思考，是一種自頂向下的設(shè)計策略。4、信息隱藏 應(yīng)該這樣設(shè)計和確定模塊，使得一個模塊內(nèi)部包含的信息（過程和數(shù)據(jù)等實現(xiàn)細(xì)節(jié)）對于不需要這些信息的模塊來說，不能訪

60、問。5、 軟件獨立性準(zhǔn)則 軟件獨立性的含義是指開發(fā)具有功能專一，模塊之間無過多相互作用的模塊。又稱為模塊獨立性準(zhǔn)則。 這種類型的模塊可以并行開發(fā)，開發(fā)容易，能減少錯誤的影響，使模塊容易組合、修改及測試。 軟件獨立性的度量標(biāo)準(zhǔn)是兩個定性指標(biāo)： 耦合性 用于描述模塊之間聯(lián)系的緊密程度。內(nèi)聚性 用于描述模塊內(nèi)部聯(lián)系的緊密程度。耦合分類：數(shù)據(jù)耦合：模塊間有且僅有數(shù)據(jù)交換控制耦合：模塊間有控制信息交換公共耦合：多個模塊通過一個公共環(huán)境相互作用。復(fù)合耦合：兩個模塊既往公共環(huán)境送變量又從公共變量里面取數(shù)據(jù)內(nèi)容耦合：一個模塊訪問另一個模塊內(nèi)的全部數(shù)據(jù)。內(nèi)聚性(cohesion)偶然型邏輯型瞬時型通訊型順序型弱