軟件技術基礎第3章.ppt

《軟件技術基礎第3章.ppt》由會員分享，可在線閱讀，更多相關《軟件技術基礎第3章.ppt（36頁珍藏版）》請在裝配圖網(wǎng)上搜索。

3 1問題定義和可行性研究3 2需求分析3 3結構化分析 SA方法 概述3 4數(shù)據(jù)流圖3 5數(shù)據(jù)詞典3 6需求分析階段的其他工作 第3章需求分析 返回主目錄 第3章需求分析 3 1問題定義和可行性研究軟件開發(fā)一般涉及用戶和開發(fā)人員 即先由用戶提出問題 然后由軟件開發(fā)人員給出問題的解答 但用戶和開發(fā)人員往往缺乏共同的語言 用戶熟悉本身的業(yè)務 如飛機訂票 但不熟悉計算機技術 軟件開發(fā)人員熟悉計算機技術但不了解用戶的業(yè)務 軟件開發(fā)人員習慣用數(shù)據(jù)結構 程序結構 編程語言等方式來討論問題 而用戶不能確切地理解這些概念 所以雙方交流時存在著隔閡 更有甚者 用戶本身也不知道他究竟要計算機做些什么 如果開發(fā)人員急于求成 在未明確軟件系統(tǒng)應該 做什么 的情況下就開始進行設計 編程 直至系統(tǒng)完成交付給用戶之后 才發(fā)現(xiàn)它不符合要求 但這時已太遲了 由此人們認識到 為了開發(fā)出滿意的軟件系統(tǒng) 開發(fā)過程應該分為兩大階段進行 第一階段是正確地確定問題 即明確地確定用戶所要解決的問題是什么 并形成關于目標系統(tǒng)的規(guī)模和報告 第二階段才是為問題尋找合適的解答 作為軟件開發(fā)組織 其開發(fā)軟件的目的是為了利益 因此 必須對該軟件項目進行可行性研究 可行性研究主要從兩方面進行 從技術角度對目標系統(tǒng)進行可行性分析 以確定目標系統(tǒng)是否有可行的解 另一方面 從成本 效益角度對目標系統(tǒng)進行可行性分析 以確定目標系統(tǒng)是否值得去解 并形成有關目標系統(tǒng)的高層邏輯模型的報告 該模型是用某種描述方法 對問題進行邏輯上的描述 抽象出問題的實際模型 并對項目的可行性給出明確說明 3 2需求分析 在可行性研究的基礎上 就必須明確軟件系統(tǒng)必須 做什么 并形成有關目標系統(tǒng)的需求說明書 這就是需求分析RequirementAnalysis 又稱需求分析階段 其目的是澄清用戶的需求 這個階段的基本任務是 用戶和軟件人員雙方一起來充分地理解用戶的要求 并把雙方共同的理解明確地表達成一份書面文檔 需求說明書 RequirementSpecification 所以分析階段的兩大任務就是 理解 和 表達 分析 就是理解問題 規(guī)格說明 就是按某種標準的方式把問題表達出來 在軟件生命期的各個階段中 分析階段是面向 問題 的 它主要是對用戶的業(yè)務活動 如飛機訂票 進行分析 明確在用戶的業(yè)務環(huán)境中 軟件系統(tǒng)應該 做什么 后面的設計 編程階段則是面向 解答 的 這時考慮的是如何構造一個滿足用戶要求的系統(tǒng) 所以 在分析階段 我們應集中考慮軟件系統(tǒng) 做什么 而盡可能少考慮系統(tǒng)將怎樣具體實現(xiàn)的問題 實現(xiàn)問題應盡量推遲到以后的階段去解決 那么什么是 用戶要求 Requirements 呢 在軟件工程中 所謂 用戶要求 或稱 需求 是指軟件系統(tǒng)必須滿足的所有性質(zhì)和限制 用戶要求通常包括功能要求 性能要求 可靠性要求 安全保密要求 開發(fā)費用 開發(fā)周期以及可使用的資源等方面的限制 其中功能要求是最基本的 它又包括數(shù)據(jù)要求和加工要求兩方面 用戶和軟件人員充分地理解了用戶的要求之后 要將共同的理解明確地寫成一份文檔 需求說明書 所以需求說明書就是 用戶要求 的明確表達 需求說明書主要有以下三個作用 1 作為用戶和軟件人員之間的合同 為雙方相互了解提供基礎 2 反映出問題的結構 可以作為軟件人員進行設計和編程的基礎 3 作為驗收的依據(jù) 即作為選取測試用例 如進行形式驗證 的依據(jù) 這三種作用對需求說明書提出了不同的 有些矛盾的要求 作為設計的基礎和驗收的依據(jù) 需求說明書應該是精確而無二義的 這樣才不致被人誤解 需求說明書越精確 以后出現(xiàn)錯誤 混淆 反復的可能性就越少 例如 本系統(tǒng)應能令人滿意地處理所有的輸入信息 是一種含糊不清的描述 驗收時無法檢查這一要求是否滿足 又如 響應時間足夠快 也是不明確的 而 響應時間小于3秒 則是精確的描述 在測試時可以檢查系統(tǒng) 滿足 還是 不滿足 這個要求 用戶能看懂需求說明書 并能發(fā)現(xiàn)和指出其中的錯誤是保證軟件系統(tǒng)質(zhì)量的關鍵 所以需求說明書必須簡明易懂 盡量不包含計算機技術中的概念和術語 使用戶和軟件人員雙方都能接受它 由于用戶往往不是一個人 而是企業(yè)組織中各個部門的好幾個工作人員 他們可能提出相互沖突的要求 分析階段必須協(xié)調(diào)和解決這些沖突 最后在需求說明書中表達的應該是一致的 無矛盾的用戶要求 由于用戶的要求時時會發(fā)生變化 需求說明書也就需作相應的修改 所以需求說明書的表達方式又必須是易于修改和維護的 總之 需求說明書應該既完整 一致 精確 無二義 又要簡明易懂并易于修改和維護 顯然 要達到這樣的目標并不容易 分析階段是保證軟件質(zhì)量的第一步 如何分析用戶要求 需求說明書用什么形式表示等都需要有一定的技術來指導 由于分析階段是同用戶進行討論 因此這個階段的方法 模型 語言和工具都必須考慮到用戶的特點 20世紀70年代以來 逐步出現(xiàn)了多種適用于分析階段的技術 但是至今還沒有出現(xiàn)既能完整精確地描述大型系統(tǒng)的用戶要求 又能簡單易懂地被廣大用戶接受的形式語言 目前大多數(shù)軟件系統(tǒng)的需求說明書還是用非形式化的方式 例如用圖形或自然語言等 表示的 3 3結構化分析 SA方法 概述 3 3 1由頂向下逐層分解軟件工程技術中 控制復雜性的兩個基本手段是 分解 和 抽象 對于一個復雜的問題 由于人的理解力 記憶力均有限 所以不可能觸及到問題的所有方面以及全部的細節(jié) 為了將復雜性降低到人可以掌握的程度 可以把大問題分割成若干個小問題 然后分別解決 這就是 分解 分解也可以分層進行 即先考慮問題最本質(zhì)的屬性 暫把細節(jié)略去 以后再逐層添加細節(jié) 直至涉及到最詳細的內(nèi)容 這就是 抽象 SA方法也是采用了這兩個基本手段 對于一個復雜的系統(tǒng) 例如銀行管理系統(tǒng) 如何理解和表達它的功能呢 SA方法使用了 由頂向下逐層分解 的方式 圖3 1中系統(tǒng)S很復雜 為了理解它 可以將它分解成S1和S2兩個子系統(tǒng) 如果子系統(tǒng)S1仍然很復雜 可以將它們再分解成S1 1和S1 2等子系統(tǒng) 如此繼續(xù)下去 直到子系統(tǒng)足夠簡單 能夠清楚地被理解和表達為止 對系統(tǒng)作了合理的逐層分解后 我們就可分別理解系統(tǒng)的每一個細節(jié) 圖3 1中的S1 1 S1 2 S2 1 S2 2等 并為每個細節(jié)寫下說明 稱為 小說明 再將所有這些 小說明 組織起來 就獲得了整個系統(tǒng)S的系統(tǒng)說明書 逐層分解 體現(xiàn)了分解和抽象的原則 它使人們不至于一下子陷入細節(jié) 而是有控制地逐步了解更多的細節(jié) 這是有助于理解問題的 圖3 1由頂向下逐層分解示例 圖3 1的頂層抽象地描述了整個系統(tǒng) 底層具體地畫出了系統(tǒng)的每一個細節(jié) 而中間層則是從抽象到具體的逐步過渡 按照這樣的方式 無論系統(tǒng)多么復雜 分析工作都可以有計劃 有步驟并有條不紊地進行 系統(tǒng)規(guī)模再大 分析工作的復雜程度也不會隨之增大 只是多分解幾層而已 所以SA方法有效地控制了復雜性 3 3 2描述方式由于目前還沒有出現(xiàn)既能精確地描述大型系統(tǒng)的用戶要求 又簡明易懂的形式語言 因此SA方法采用了介于形式語言和自然語言之間的描述方式 它雖然不如形式語言精確 但是簡明易懂 所表達的意義也比較明確 用SA方法獲得的需求說明書由以下幾部分組成 1 一套分層的數(shù)據(jù)流圖 2 一本數(shù)據(jù)詞典 3 一組小說明 4 補充材料 這套文檔中 數(shù)據(jù)流圖 描述系統(tǒng)的分解 即描述系統(tǒng)由哪些部分組成 各部分之間有什么聯(lián)系等 數(shù)據(jù)詞典 描述系統(tǒng)中的每一個數(shù)據(jù) 小說明 則詳細描述系統(tǒng)中的每一個加工所完成的操作 上述資料再加上視系統(tǒng)而定的各種補充材料就可明確而完整地描述一個系統(tǒng)的功能 SA方法在描述方式上的特點是盡量采用圖形表示 因為圖形比較形象 直觀 易于理解 一張圖的表達效果可能比幾千字的敘述還要好 3 4數(shù)據(jù)流圖 數(shù)據(jù)流圖主要用來描述目標系統(tǒng)的邏輯模型 下面分析數(shù)據(jù)流圖的基本成分 SA方法采用 分解 的方式來理解一個復雜的系統(tǒng) 分解 需要有描述的手段 數(shù)據(jù)流圖 DataFlowDiagram 就是作為描述 分解 的手段而引進的 對大多數(shù)數(shù)據(jù)處理系統(tǒng)來說 從數(shù)據(jù)流的角度來描述一個企事業(yè)組織的業(yè)務活動是比較合適的 數(shù)據(jù)流圖描述了一個組織有哪幾個組成部分 也描述了來往于各部分之間的數(shù)據(jù)流 下面先看一個例子 假定要為某培訓中心研制一個計算機管理系統(tǒng) 我們首先需分析這個系統(tǒng)應該做些什么 為此必須分析培訓中心的業(yè)務活動 培訓中心是一個功能很復雜的系統(tǒng) 它為在職人員開設許多門課程 有興趣的人可以來電或來函報名選修某門課程 培訓中心要收取一定的費用 學員通過支票付款 也可以來電或來函查詢課程計劃等有關事宜 培訓中心的日常業(yè)務是 將學員發(fā)來的電報 信件 電話收集分類后 按幾種不同情況處理 如果是報名的 則將報名數(shù)據(jù)送給負責報名事務的職員 他們要查閱課程文件 檢查某課程是否額滿 然后在學生文件 課程文件上登記 并開出報名單交財務部門 財務人員再開出發(fā)票經(jīng)復審后通知學員 如果是付款的 則由財務人員在帳目文件上登記 再經(jīng)復審后發(fā)給學員一張通知單 如果是查詢的 則交查詢部門查閱課程文件后給出答復 如果是想注銷原來已選修的課程 則由注銷人員在課程 學生 帳目文件上作相應修改 經(jīng)復審后通知學員 對一些要求不合理的函電 培訓中心將拒絕處理 我們可以用圖3 2的數(shù)據(jù)流圖描述這個系統(tǒng)的 分解 這張圖告訴我們 系統(tǒng)分解成 收集 分類 報名 等八個部分 這些部分之間通過圖中所示的數(shù)據(jù)流進行聯(lián)系 要理解整個系統(tǒng)只需分別理解這八個部分就可以了 由于每個部分比整個系統(tǒng)小多了 所以分析工作就可以簡化 從圖3 2看出 數(shù)據(jù)流圖有四種基本成分 1 數(shù)據(jù)流 用箭頭表示 2 加工 用圓表示 3 文件 用直線段表示 4 數(shù)據(jù)流的源點或終點 用方框表示 數(shù)據(jù)流圖中的每個成分都有一個互不相同的名字來加以區(qū)分 下面分別討論各種成分 1 數(shù)據(jù)流數(shù)據(jù)流由一組固定成分的數(shù)據(jù)組成 在圖3 2中 數(shù)據(jù)流 報名請求 由 姓名 年齡 性別 單位名 課程名 等成分組成 數(shù)據(jù)流 發(fā)票 由 姓名 單位名 金額 組成 它們的組成成分都是確定的 圖3 2數(shù)據(jù)流圖 數(shù)據(jù)流可以從加工流向加工 也可以從加工流向文件或從文件流向加工 也可以從源點流向加工或從加工流向終點 一般來說 除了流向文件或從文件流出的數(shù)據(jù)流不必命名之外 在這種情況下 有文件名已足夠了 每個數(shù)據(jù)流都必須有一個合適的名字 名字一方面是為了區(qū)別 同時也是給人一個直觀的印象 使人容易理解這個數(shù)據(jù)流的含義 應該注意的是 數(shù)據(jù)流圖中描述的是數(shù)據(jù)流而不是控制流 圖3 3中 取下一張卡片 是一個控制流而不是數(shù)據(jù)流 因為并沒有任何數(shù)據(jù)沿著這個箭頭流動 所以這個箭頭應該從圖中刪去 習慣使用框圖 程序流程圖 的軟件人員特別應該注意不要犯這種錯誤 圖3 3數(shù)據(jù)流和控制流 2 加工加工是對數(shù)據(jù)進行的操作 在圖3 2中 報名 產(chǎn)生發(fā)票 查詢 等都是加工 加工的名字也應適當?shù)胤从尺@個加工的含義 使之容易理解 3 文件文件是暫時存儲的數(shù)據(jù) 圖3 2中有 學生 課程 帳目 等文件 文件的名字也應適當?shù)剡x擇 以便理解 我們還應注意加工與文件之間數(shù)據(jù)流的方向 如果加工要讀文件 則數(shù)據(jù)流是從文件流出的 如果加工要寫文件或修改文件 雖然修改文件一般先要讀文件 但其本質(zhì)是寫 則數(shù)據(jù)流是流向文件的 如果加工既要讀文件 除了修改文件之外 又要寫文件 則數(shù)據(jù)流是雙向的 在圖3 4中 加工 檢查拼寫的正確性 對輸入的詞進行檢查 圖3 4源點和終點 4 源點和終點一個數(shù)據(jù)處理系統(tǒng)的內(nèi)部用數(shù)據(jù)流 文件和加工三種成分表示一般已足夠了 然而為了便于理解 有時還可以畫出數(shù)據(jù)流的源點和終點來說明它的來龍去脈 源點和終點通常是存在于系統(tǒng)之外的人員或組織 如圖3 2中 學員 是數(shù)據(jù)流 函電 的源點 也是數(shù)據(jù)流 通知單 的終點 畫出源點和終點只是起到注釋作用和幫助理解而已 由于它們是系統(tǒng)之外的事物 我們對此是不大關心的 所以源點和終點的表達不必很嚴格 總之 數(shù)據(jù)流圖從 數(shù)據(jù) 和 數(shù)據(jù)的加工 這兩個相互補充的方面來表達一個數(shù)據(jù)處理系統(tǒng) 它從數(shù)據(jù)的角度描述它們作為輸入進入系統(tǒng) 經(jīng)過某個加工 再經(jīng)過某個加工 或者合并 或者分解 或者存儲 最后成為輸出離開系統(tǒng) 經(jīng)驗證明 對數(shù)據(jù)處理系統(tǒng)來說 從數(shù)據(jù)角度觀察問題一般能夠較好地抓住問題的本質(zhì) 并描述出系統(tǒng)的概貌 但是 數(shù)據(jù)流圖只描述了系統(tǒng)的 分解 它并沒有表達出每個數(shù)據(jù)和加工的具體含義 這些信息需在 數(shù)據(jù)詞典 和 小說明 中表達出來 數(shù)據(jù)流圖的優(yōu)點是直觀 容易理解 容易被一組人同時進行審查 如果圖中有錯誤 一般也比較顯眼 容易被人們發(fā)現(xiàn) 實踐證明 從事數(shù)據(jù)處理工作的人 包括用戶和軟件開發(fā)人員 都很容易接受這個描述方式 3 5數(shù)據(jù)詞典 3 5 1數(shù)據(jù)詞典與數(shù)據(jù)流圖的聯(lián)系數(shù)據(jù)流圖描述了系統(tǒng)的 分解 即描述了系統(tǒng)由哪幾部分組成 各部分之間有什么聯(lián)系等 但是并沒有說明系統(tǒng)中各個成分是什么含義 因此僅僅一套數(shù)據(jù)流圖并不能構成系統(tǒng)的需求說明書 只有為圖中出現(xiàn)的每一個成分都給出明確定義之后 才較完整地描述了一個系統(tǒng) 數(shù)據(jù)流圖中所有名字的定義就構成了一本詞典 同日常使用的詞典一樣 SA方法所用的詞典也是這樣一個工具 當我們不知道某個名字的含義時 借助于它就可查出這個名字的含義 詞典中所有條目應該按一定次序排列起來 這樣才能供人們方便地查閱 數(shù)據(jù)流圖與詞典是密切聯(lián)系的 兩者結合在一起才構成了 需求說明書 單獨一套數(shù)據(jù)流圖或單獨一本詞典都是沒有任何意義的 數(shù)據(jù)流圖中出現(xiàn)的每一個數(shù)據(jù)流名 每一個文件名和每一個加工名在詞典中都應有一個條目給出這個名字的定義 此外 在定義數(shù)據(jù)流 文件和加工時 又要引用到它們的組成部分 所以每一個組成部分在詞典中也應有一個條目給出其定義 3 5 2數(shù)據(jù)詞典條目的各種類型詞典中包含以下四種類型的條目 1 數(shù)據(jù)流 2 文件 3 數(shù)據(jù)項 指不能再分解的數(shù)據(jù)單位 4 加工 數(shù)據(jù)流 文件和數(shù)據(jù)項等數(shù)據(jù)型條目構成了數(shù)據(jù)詞典 DataDictionary 1 數(shù)據(jù)流條目數(shù)據(jù)流條目給出某個數(shù)據(jù)流的定義 它通常是列出該數(shù)據(jù)流的各組成數(shù)據(jù)項 如圖3 2中的數(shù)據(jù)流 報名單 由 姓名 單位名 年齡 性別 和 課程名 等數(shù)據(jù)項組成 詞典中 報名單 這個條目就可寫成報名單 姓名 單位名 年齡 性別 課程名有些數(shù)據(jù)流的組成很復雜 一下子列出它所有的數(shù)據(jù)項可能不易使人理解 此時同樣可采用 由頂向下逐步分解 的方式來說明 例如某學校管理系統(tǒng)中 有個名為 課程 的數(shù)據(jù)流 它由 課程名 教員 教材 和 課程表 組成 而 課程表 又由 星期幾 第幾節(jié) 和 教室 組成 則詞典中可以建立 課程 及 課程表 兩個條目 它們分別是課程 課程名 教員 教材 課程表課程表 星期幾 第幾節(jié) 教室 這樣 只要依次查閱這兩個條目 就可確切地理解 課程 這個名字的含義 給出數(shù)據(jù)流的定義時 需要使用一些簡單的符號 如 表示 與 表示 或 即選擇括號中的某一項 表示 重復 即括號中的項要重復若干次 重復次數(shù)的上 下限也可在括號邊上標出 表示 可選 即括號中的項可能沒有 分析員可根據(jù)自己的習慣 選擇使用類似的符號 其中自定義的符號應說明其功能 下面再給出一個數(shù)據(jù)流條目的例子 數(shù)據(jù)流 發(fā)票 由1 5個 發(fā)票行 組成 而每個 發(fā)票行 又由 貨名 數(shù)量 單位 和 總價 組成 則詞典中的 發(fā)票 條目是發(fā)票 貨名 數(shù)量 單價 總價 也可分別建立 發(fā)票 和 發(fā)票行 兩個條目 它們是發(fā)票 發(fā)票行 發(fā)票行 貨名 數(shù)量 單價 總價2 文件條目文件條目給出某個文件的定義 同數(shù)據(jù)流一樣 文件的定義通常是列出其記錄的組成數(shù)據(jù)項 此外 文件條目還可指出文件的組織方式 如 按帳號遞增次序排列 等 是一個例子 帳目 帳號 戶名 地址 款額 日期組織 按帳號遞增次序排列 3 數(shù)據(jù)項條目數(shù)據(jù)項條目給出某個數(shù)據(jù)項的定義 這通常是該數(shù)據(jù)項的值類型 允許值等 例如 帳號 這個數(shù)據(jù)項的值可以是00000 99999之間的任意整數(shù) 則詞典條目 帳號 可寫成 帳號 00000 99999又如 數(shù)據(jù)項 日期 可取1997 1 12 1 31等值 則詞典條目 日期 可寫成 日期 1997 1 12 1 31 有了這樣的詞典 我們只要依次查閱 帳目 帳號 日期 等條目 就可了解文件 帳目 的精確含義了 有些數(shù)據(jù)項本身名字已足以說明其含義 如詞典條目 學生 中 學生 姓名 年齡 性別 班級這里 姓名 年齡 性別 等數(shù)據(jù)項的含義是不言而喻的 所以就不必再解釋了 這些名字稱為是 自定義 的 自定義的詞在詞典中就不必再給出條目了 詞典條目的具體格式往往因系統(tǒng)而異 它也同用戶習慣使用的表達方式有關 3 6需求分析階段的其他工作 除了前面討論的工作之外 需求分析階段還應完成下列工作 1 確定設計限制軟件的設計要受到系統(tǒng)以外許多因素的影響 如成本 進度 可用的軟硬件資源等 因此分析還必須確定設計的限制 并試圖說明每種限制都是合理的 2 確定驗收準則在同用戶討論時 分析員應該提出這樣的問題 如果明天就將系統(tǒng)交給你 你憑什么認為這個系統(tǒng)是成功的 這個問題和相應的回答便構成了一組驗收準則 驗收準則應該盡可能具體 用于確認每個主要功能的測試方法也應同時確定下來 用戶往往會很一般地回答上述問題 而分析員必須尋求精確的答復 他應該認識到 如果不能精確地規(guī)定這些準則 則說明用戶需求還是模糊的 驗收準則是測試計劃的基礎 如果被忽視了 就是開發(fā)人員的失職 3 編寫 初步用戶手冊 初步用戶手冊 為系統(tǒng)的操作員描繪了軟件系統(tǒng)的外貌 并能說明需求分析工作是否已確定了軟件系統(tǒng)的所有主要輸入和輸出 該手冊還可用來評價系統(tǒng)的人機界面 用戶在審查 初步用戶手冊 時經(jīng)常會這樣說 我想這不是我們啟動這個功能的方式 這不行 因為 這些評論最好在分析階段就做出 到系統(tǒng)驗收時才說就太遲了 需求說明書寫成之后 用戶和分析員應該對它進行復查 爭取系統(tǒng)還只在紙上時就發(fā)現(xiàn)其中的錯誤并及時糾正 開發(fā)人員應該檢查是否正確地理解了問題的整個含義 仔細評價全部文檔的完整性 一致性 正確性和清晰性 復查的結果幾乎總是修改并重新定義某些需求 需求分析中的這些反復正是所期望的 甚至是值得提倡的 最后 一份能被用戶和開發(fā)人員雙方共同接受的需求說明書終于產(chǎn)生 需求說明書的篇幅可能較長 我們可將各種圖形和文字材料適當裝訂起來 分成章節(jié) 再加上前言 目錄等 編成一本易于閱讀的手冊 需求說明書將為軟件系統(tǒng)的設計 實現(xiàn)和驗收奠定良好的基礎 獲得用戶和開發(fā)人員共同確認的需求說明書 就是分析階段勝利完成的里程碑