【正文】 示意圖 結(jié)構(gòu)化分析方法 ? 需求分析最常用的方法是結(jié)構(gòu)化分析方法 （ Structured Analysis） ， 它適用于分析大型數(shù)據(jù)處理系統(tǒng) ? 該方法簡明 ， 易于掌握 ， 與設(shè)計階段的結(jié)構(gòu)化方法相銜接 ， 將取得良好的設(shè)計效果 結(jié)構(gòu)化分析方法的基本思想和步驟 ? 結(jié)構(gòu)化分析方法的基本思想是采用 “ 分解 ”和 “ 抽象 ” 的基本手段 ， 由頂向下逐層分解 ，具體步驟為： 1. 理解當前的現(xiàn)狀環(huán)境 ， 建立當前系統(tǒng)的 “ 具體模型 ” 2. 從當前系統(tǒng)的 “ 具體模型 ” 抽象出當前系統(tǒng)的“ 邏輯模型 ” 3. 分析目標系統(tǒng)與當前系統(tǒng)在邏輯上的差別 ， 建立目標系統(tǒng)的邏輯模型 4. 為了對目標系統(tǒng)做完整的描述 ， 還需要考慮人機界面和其他一些問題 結(jié)構(gòu)化分析方法的描述方法 ? 數(shù)據(jù)流圖 （ DFD） 和分層的數(shù)據(jù)流圖 ? 數(shù)據(jù)詞典 （ DD, Data Dictionary） ? 加工說明 (1)數(shù)據(jù)流圖 (DFD, Data Flow Diagram) ? 數(shù)據(jù)流圖以圖形的方式表示系統(tǒng)中的信息變換和傳遞的過程 ， 數(shù)據(jù)流圖的基本符號只有下列四種： – 數(shù)據(jù)流 – 加工 – 數(shù)據(jù)存儲 – 數(shù)據(jù)源點及數(shù)據(jù)終點 ? 畫 DFD圖的方法：由外向里 ， 自頂而下 ， 逐層分解 數(shù)據(jù)流圖的基本符號 ? 數(shù)據(jù)流 – 數(shù)據(jù)流是具有名字且具有流向的數(shù)據(jù) ， 用標有名字的箭頭表示 。 Technique 體現(xiàn)原則的途徑和步驟 Methodology 方法和技術(shù)的組合，支持整個軟件工程過程 Tools 支持方法、技術(shù)和方法學的軟件 一般性原則 ? 嚴格性與形式化 ? 復(fù)雜性和分解 ? 模塊化 ? 抽象性和細化 ? 變更預(yù)見性 ? 通用性與復(fù)用性 ? 遞增式 軟件質(zhì)量管理原則 ? 產(chǎn)品質(zhì)量以滿足用戶需求為最高準則 ? 質(zhì)量第一 ? 以人為本 ? 質(zhì)量與生產(chǎn)率 ? 質(zhì)量成本 ? 密切與用戶的聯(lián)系 ? 盡早排除缺陷 ? 實施過程質(zhì)量控制 文檔編制原則 ? 在文檔標準基礎(chǔ)上剪裁 ? 注意讀者對象 ? 便于使用和查找 ? 使用術(shù)語 、 概念不應(yīng)有矛盾 ? 描述的精確性 ， 無多義性 ? 專職人員與開發(fā)人員結(jié)合 ? 獨立性 需求分析與定義原則 ? 編制需求規(guī)格說明以前 ， 必須十分明確要解決的問題 ，即應(yīng)先明確需求 ? 真正弄清需求 ， 還應(yīng)包括為什么這樣定義 ? 需求不清必將導致預(yù)算不準 – 總結(jié)產(chǎn)生錯誤的原因： ? 需求變更 ， 遺漏重要需求 ， 與用戶交流不暢 ? 需求分析不充分 ， 需求規(guī)格說明質(zhì)量低劣 ? 發(fā)現(xiàn)需求規(guī)格說明中有問題 ， 應(yīng)立即著手解決 ， 不可將其帶入后續(xù)開發(fā)階段 ? 需求規(guī)格說明中不應(yīng)含有待確定的部分 ? 進行需求分析時不做設(shè)計 ， 不應(yīng)將需求分析做什么與如何做混淆 設(shè)計原則 ? 重視需求向設(shè)計轉(zhuǎn)化工作 ， 必要時比較多個設(shè)計方案 ? 設(shè)計應(yīng)能和需求對應(yīng) ， 保證每項需求均在設(shè)計中得到體現(xiàn) ? 設(shè)計文檔是設(shè)計的成果 ， 頭腦中的設(shè)想不是設(shè)計 ? 盡可能復(fù)用一切可復(fù)用的部分 ? 設(shè)計應(yīng)易于變更 、 易于維護 、 易于排錯 ? 優(yōu)秀的設(shè)計出自優(yōu)秀人才之手 編碼原則 ? 簡明清晰 ? 盡可能少用 、 甚至不用全局變量 ? 程序執(zhí)行速度不應(yīng)優(yōu)先于正確性的考慮 ? 命名易記 ， 充分注釋 ， 命名唯一 ， 可追溯 ? 注意常見的規(guī)律是：編碼錯誤通常相對集中 管理原則 ? 大型復(fù)雜項目管理重于技術(shù) ? 人員不在多 ， 而在精 ? 計劃指標應(yīng)切合實際 ， 不作不切實際的計劃 ? 注意收集 、 積累數(shù)據(jù) ? 不求一次估算能十分精確 ， 但求不斷調(diào)整 ? 大型項目重視風險分析 ? 項目進展快需分析原因 ， 不可盲目樂觀 ? 項目完成以后 ， 總結(jié)分析有益于積累經(jīng)驗 軟件過程改進 ? 質(zhì)量依賴于過程 ? 過程需要管理 ? 軟件過程 –包括哪些過程 –如何改進 ?能力成熟度水平： CMM五級 ?軟件過程改進 （ SPI） 不成熟過程的特征 ? 隨意的 ? 非強制性的 ? 主要依賴于實踐者 ? 產(chǎn)品的功能 、 質(zhì)量和進度常有沖突 ? 引入新技術(shù)時的風險 ? 質(zhì)量難以預(yù)測 成熟過程的特征 ? 工作按計劃有序地進行 ? 過程 、 規(guī)程 、 文檔規(guī)范 –有定義 、 文檔化 –易理解 、 易使用 、 可裁減 –可持續(xù)改進 ? 管理的可見性 ? 產(chǎn)品和過程可度量 、 可預(yù)測 ? 新技術(shù)可以及時得到有效應(yīng)用 ? CMU/SEI 5級 優(yōu)化層 * 過程更改管理 * 技術(shù)更改管理 * 錯誤預(yù)防 4級 管理層 * 質(zhì)量管理 * 過程量化管理 3級 定義層 * 同級評審 組間協(xié)作 * 軟件產(chǎn)品工程 * 軟件集成管理 培訓計劃 * 軟件過程定義 * 軟件過程要點 2級 可重復(fù)層 軟件配置管理 軟件質(zhì)量保證 軟件子合同管理 * 軟件項目追蹤與監(jiān)控 軟件項目計劃 需求管理 1級 初始層 軟件過程成熟度模型的關(guān)鍵子過程域 能力成熟度模型 第三部分 軟件工程 1. 軟件工程的基本概念 2. 軟件開發(fā)方法與工作模型 3. 結(jié)構(gòu)化開發(fā)方法概述 4. 習題 2 軟件開發(fā)方法與工作模型 ? 結(jié)構(gòu)化開發(fā)方法 ? 原型化方法 ? 面向?qū)ο蟮拈_發(fā)方法 結(jié)構(gòu)化開發(fā)方法 ? 結(jié)構(gòu)化方法是現(xiàn)有軟件開發(fā)方法中最成熟 ， 應(yīng)用最廣泛的方法 ? 結(jié)構(gòu)化開發(fā)方法的主要特點是快速 ， 自然和方便 ? 結(jié)構(gòu)化程序設(shè)計的概念首先是從編寫程序中使用轉(zhuǎn)向 （ GOTO ） 語句引起的 – GOTO語句的過多使用使得程序結(jié)構(gòu)混亂 ，容易出錯 ， 且出錯后不易發(fā)現(xiàn)和更正 結(jié)構(gòu)化開發(fā)方法 ? 結(jié)構(gòu)化開發(fā)方法的出發(fā)點 – 為了保證程序設(shè)計的質(zhì)量 – 使設(shè)計程序具有易讀性 、 易理解性 、 通用性好 ， 執(zhí)行時具有較高的效率 ? 結(jié)構(gòu)化開發(fā)方法的基本要求 – 在詳細設(shè)計階段所有的模塊只用三種基本控制結(jié)構(gòu) ? 單入口 、 單出口和順序 ? 選擇 ? 循環(huán) – 在設(shè)計過程中采用自頂向下逐步求精的設(shè)計方法 結(jié)構(gòu)化開發(fā)方法 ? 結(jié)構(gòu)化開發(fā)方法的組成 – 70年代初 結(jié)構(gòu)化程序設(shè)計方法 SP法 – 70年代中 結(jié)構(gòu)化設(shè)計方法 SD法 – 70年代末 結(jié)構(gòu)化程序分析方法 SA法 ? SA， SD， SP法相互銜接 ， 形成了一整套開發(fā)方法 ? 若將 SA， SD法結(jié)合起來 ， 又稱為結(jié)構(gòu)化分析與設(shè)計技術(shù) （ SADT技術(shù) ） 結(jié)構(gòu)化方法的工作模型 ? 瀑布模型 （ Waterfall Model） 是結(jié)構(gòu)化方法的工作模型 ? 但從 80年代開始 ， 逐漸發(fā)現(xiàn)其不足： – 軟件開發(fā)過程是一個充滿回朔過程 ， 而瀑布模型將其分割為獨立的幾個階段 ， 不能從本質(zhì)上反映軟件開發(fā)過程本身的規(guī)律 – 過分強調(diào)復(fù)審 ， 并不能完全避免較為頻繁的變動 ? 盡管如此 ， 瀑布模型仍然是開發(fā)軟件產(chǎn)品的一個行之有效的工程模型 2 軟件開發(fā)方法與工作模型 ? 結(jié)構(gòu)化開發(fā)方法 ? 原型化方法 ? 面向?qū)ο蟮拈_發(fā)方法 原型化方法 ? 原型是軟件開發(fā)過程中軟件的一個早期可運行的版本 ， 它反映了最終系統(tǒng)的部分重要特征 ? 原型化方法的基本思想是花費少量代價建立一個可運行的系統(tǒng) ， 使用戶及早獲得學習的機會 ，原型化方法又稱速成原型法 （ Rapid Prototyping） ? 強調(diào)的是軟件開發(fā)人員與用戶的不斷交互 ， 通過原型的演進不斷適應(yīng)用戶任務(wù)改變的需求 ? 將維護和修改階段的工作盡早進行 ， 使用戶驗收提前 ， 從而使軟件產(chǎn)品更加適用 原型化方法分類 ? 原型化方法按運用原型的目的和方式的不同分為： – 快速建立漸進原型 （ RSP法 ， Rapid Sequential Prototyping ） ? 該法建立的原型反映了系統(tǒng)的某些特征 ， 讓用戶學習 ， 有利于獲得更加精確的需求說明書 ， 后階段的工作仍按照瀑布模型開發(fā) – 快速建立需求規(guī)格原型 （ RCP法 ， Rapid Cyclic Prototyping ） ? 該法采用循環(huán)漸進的開發(fā)方式 ， 對系統(tǒng)模型作連續(xù)精化 ， 將系統(tǒng)需要具備的性質(zhì)逐步添加上去 ， 直至所有性質(zhì)全部滿足 ， 此時的原型模型也就是最終的產(chǎn)品 ? 速成原型適合于開發(fā) “ 探索型 ” ， “ 實驗型 ” 與 “ 進化型 ” 一類的軟件系統(tǒng) ? 速成原型的工作模型是一個循環(huán)的模型 循環(huán)的速成原型工作模型 ? 速成原型循環(huán)方式步驟： – 快速分析 ? 快速確定軟件系統(tǒng)的基本要求 ? 確定原型所要體現(xiàn)的特征 （ 界面 ，總體結(jié)構(gòu) ， 功能 ， 性能 ） – 構(gòu)造原型 ? 在快速分析的基礎(chǔ)上根據(jù)基本規(guī)定說明 ， 忽略細節(jié) ， 只考慮主要特征 ，快速構(gòu)造一個可運行的系統(tǒng) ? 它有三類原型：用戶界面原型 ， 功能原型 ， 性能原型 – 運行和評價原型 ? 用戶試用原型并與開發(fā)者之間頻繁交流 ， 發(fā)現(xiàn)問題 ， 目的是驗證原型的正確性 – 修正與改進 ? 對原型進行修改 ， 增刪 快速分析或修改 運行 構(gòu)造 評價 原型 循環(huán)的速成原型工作模型 ? 細化的速成原型工作模型 快速分析，確定初步規(guī)格說明 構(gòu)造原型 運行 /評價原型 原型完成否 要細部說明否 效果滿意否 嚴格說明細部 整理原型提供文檔 修正改進原型 N N Y Y Y N 2 軟件開發(fā)方法與工作模型 ? 結(jié)構(gòu)化開發(fā)方法 ? 原型化方法 ? 面向?qū)ο蟮拈_發(fā)方法 面向?qū)ο蟮拈_發(fā)方法 ? 面向過程的開發(fā)方法 –面向數(shù)據(jù)流設(shè)計 –面向數(shù)據(jù)結(jié)構(gòu)設(shè)計 ? 面向?qū)ο蟮拈_發(fā)方法 （ OOSD） –面向?qū)ο蟮姆治?（ OOA） –面向?qū)ο蟮脑O(shè)計 （ OOD） –面向?qū)ο蟮某绦蛟O(shè)計 （ OOP） 面向過程的開發(fā)方法 ? 早期的高級語言都是面向過程的 ? 程序設(shè)計者必然要專注于： –程序?qū)?shù)據(jù)的處理過程 ——面向數(shù)據(jù)流設(shè)計 –數(shù)據(jù)結(jié)構(gòu) ——面向數(shù)據(jù)結(jié)構(gòu)設(shè)計 ? 因此 ， 由軟件解決的問題通常用軟件系統(tǒng)的 數(shù)據(jù)流圖 或 數(shù)據(jù)結(jié)構(gòu) 來表示 面向過程的開發(fā)方法 ? 數(shù)據(jù)流圖 –描述軟件系統(tǒng)的數(shù)據(jù)從輸入到輸出的流程 ，適用于幾乎所有順序處理的軟件 ? 數(shù)據(jù)結(jié)構(gòu) –描述軟件系統(tǒng)的輸入輸出數(shù)據(jù)結(jié)構(gòu) ， 適用于數(shù)據(jù)處理 ， 尤其輸入與輸出數(shù)據(jù)結(jié)構(gòu)相似的軟件系統(tǒng) 面向?qū)ο蟮拈_發(fā)方法 (OOSD) ? 面向?qū)ο蟮拈_發(fā)方法 （ OOSD， ObjectOriented Software Development） –根據(jù)穩(wěn)定的對象建立系統(tǒng)模型 ， 可很好地適應(yīng)需要的變化 –具有良好的可維護性 、 可擴充性和可重用性 –是軟件工程領(lǐng)域的一個研究重點 –被譽為 90年代軟件的核心技術(shù)之一 面向?qū)ο蟮拈_發(fā)方法 ——基本思想 ? 對問題領(lǐng)域進行自然的分割 ， 以便接近人類通常思維的方式 ? 建立問題領(lǐng)域的模型 ， 以便對客觀的信息實體進行結(jié)構(gòu)和行為的模擬 ， 從而使設(shè)計的軟件更直接地表現(xiàn)問題的求解過程 ? 以對象作為最基本的元素分析和解決問題的核心 面向?qū)ο蟮拈_發(fā)方法 ——組成 ? 面向?qū)ο蟮拈_發(fā)方法的組成 –面向?qū)ο蟮姆治?（ OOA， ObjectOriented Analysis） –面向?qū)ο蟮脑O(shè)計 （ OOD， ObjectOriented Design） –面向?qū)ο蟮某绦蛟O(shè)計 （ OOP， ObjectOriented Programming） ? OOP是 OOSD的基礎(chǔ) ? OOA和 OOD是應(yīng)用 OOP的基礎(chǔ) 面向?qū)ο蟮姆治? (OOA) ? OOA分析階段將系統(tǒng)水平劃分為五個層次 – 主體 – 類和對象 – 結(jié)構(gòu) – 屬性 – 方法 ? OOA的任務(wù)就是通過分析問題域 ， 建立系統(tǒng)的概念模型 面向?qū)ο蟮姆治? (OOA) ? OOA提供了三種模型： – 信息模型 ——定義構(gòu)成系統(tǒng)的類和對象 ， 它們的屬性與操作 – 狀態(tài)模型 ——描述系統(tǒng)的控制結(jié)構(gòu) ， 即描述任何時刻對象的聯(lián)系以及聯(lián)系的變化 ， 或稱為時序 ，常用狀態(tài)圖和事件追蹤圖來描述 – 處理模型 ——描述系統(tǒng)內(nèi)部數(shù)據(jù)的傳送和處理方法 ? 面向?qū)ο蟮姆治?（ OOA） 和設(shè)計 （ OOD） 就是把面向?qū)ο蟮姆椒☉?yīng)用到軟件工程的分析和設(shè)計階段 ， 從而建立更加