【正文】 11 軟件危機(jī)的原因 ? 軟件是邏輯產(chǎn)品，開發(fā)進(jìn)度、成本難以估計(jì) ? 缺乏或不完整、不一致的文檔給維護(hù)帶來困難 ? 用戶對(duì)軟件需求的描述往往不夠精確，有遺漏，有二義 ? 軟件開發(fā)人員對(duì)需求的理解與用戶的本來愿望有差異 ? 大型軟件項(xiàng)目需多人協(xié)同完成，缺乏管理經(jīng)驗(yàn) ? 開發(fā)人員不能有效地、獨(dú)立自主地處理大型軟件的全部關(guān)系 ? 缺乏有力的方法學(xué)和工具的支持 ? 軟件項(xiàng)目的特殊性和人類智力的局限性 12 克服軟件危機(jī)的途徑 ? 消除 錯(cuò)誤的概念和做法 ? 推廣 使用成功的開發(fā)技術(shù)和方法 ? 使用 軟件工具和軟件工程支持環(huán)境 ? 加強(qiáng)軟件 管理 擺脫軟件危機(jī)的出路： 軟件開發(fā)的 工程化 和 標(biāo)準(zhǔn)化 13 軟件工程相關(guān)概念 ? 軟件工程 : 軟件工程是用科學(xué)知識(shí)和技術(shù)原理來定義、開發(fā)、維護(hù)軟件的一門綜合性的交叉學(xué)科，軟件工程是開發(fā)與維護(hù)軟件的規(guī)范化系統(tǒng)方法。 事后負(fù)責(zé)人 ：“ …… 正象一只逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷的越深。這也使得軟件的錯(cuò)誤導(dǎo)致人員傷亡成為了可能。 宇航員：弗拉迪米爾 危機(jī)實(shí)例（ 1）： 1963年美國(guó)飛往火星的火箭探測(cè)器爆炸，造成 1000萬美元 (數(shù)億美元 )的損失。 ?必須維護(hù) — 糾錯(cuò)和變更。 ?難以度量 — 難定量測(cè)量。 ?持久性 — 無時(shí)間損壞。 ?嚴(yán)密性 — 是邏輯產(chǎn)品。軟件工程概述 數(shù)據(jù)庫與軟件工程第二部分 1 2 ?軟件工程綜述 ?軟件生存周期 ?軟件質(zhì)量與質(zhì)量保證 ?軟件工程管理 ?軟件開發(fā)環(huán)境 3 ?軟件發(fā)展的三個(gè)階段 ?軟件工程相關(guān)概念 ?軟件工程目標(biāo) ?軟件工程三要素 什么是計(jì)算機(jī)軟件？ ? 計(jì)算機(jī)軟件指計(jì)算機(jī)系統(tǒng)中的 程序及其文檔 ?程序是計(jì)算任務(wù)的處理對(duì)象和處理規(guī)則的描述 ? 計(jì)算任務(wù)：任何以計(jì)算機(jī)為處理工具的任務(wù) ? 處理對(duì)象：數(shù)據(jù)（如數(shù)據(jù)、文字、圖形、圖像、聲音等，它們只是表示，而無含義）或信息（數(shù)據(jù)及有關(guān)的含義） ? 處理規(guī)則一般指處理的動(dòng)作和步驟。程序必須裝入計(jì)算機(jī)內(nèi)才能工作 ?文檔是為了便于了解程序所需的 闡明性 資料，文檔一般是給人看的，不一定裝入計(jì)算機(jī) 4 5 軟件的特點(diǎn)： ?抽象性 — 不是實(shí)物。 ?智力性 — 思維過程。 ?一次性 — 創(chuàng)造性的產(chǎn)物。 ?易出錯(cuò) — 信息轉(zhuǎn)移造成。 6 軟件發(fā)展的三個(gè)階段 ?程序設(shè)計(jì)時(shí)代（ 5060年代） 軟件指程序，軟件開發(fā)關(guān)注程序編寫，用匯編及機(jī)器語言 ?程序系統(tǒng)時(shí)代（ 6070年代） 軟件指程序及說明書，軟件開發(fā)包括程序設(shè)計(jì)和測(cè)試，用高級(jí)語言 ?軟件工程時(shí)代（ 70年代以后） 軟件開發(fā)包括軟件生命期，用軟件語言（包括需求定義語言、軟件功能語言、軟件設(shè)計(jì)語言、程序設(shè)計(jì)語言等） 7 軟件工程相關(guān)概念 ? 軟件危機(jī) : 在軟件開發(fā)過程中遇到的問題找不到解決的辦法，致使問題積累起來形成了日益尖銳的矛盾。原因是用于控制火星探測(cè)器的計(jì)算機(jī)軟件 FORTRAN程序： DO 5 I=1， 3 誤寫 為： DO 5 I= 危機(jī)實(shí)例（ 2）： 1967年蘇聯(lián) “ 聯(lián)盟一號(hào) ” 載人宇宙飛船在返航時(shí)，由于軟件忽略一個(gè)小數(shù)點(diǎn)，在進(jìn)入大氣層時(shí)因打不開降落傘而燒毀?？岂R洛夫 8 軟件工程相關(guān)概念 ? 軟件危機(jī) : 危機(jī)實(shí)例（ 3）： 人員傷亡：由于計(jì)算機(jī)軟件被廣泛應(yīng)用于包括醫(yī)院等與生命息息相關(guān)的行業(yè)。 Therac25的意外： (在軟件工程界被大量引用的案例 ) 在 1985年 六月到 1987年 一月之間 , 六個(gè)已知的醫(yī)療事故來自于Therac25錯(cuò)誤地超過劑量 , 導(dǎo)致患者死亡或嚴(yán)重輻射灼傷 9 軟件工程相關(guān)概念 ? 軟件危機(jī) : 危機(jī)實(shí)例（ 4）： IBM公司 19631966年開發(fā) IBM360操作系統(tǒng)，項(xiàng)目花了 5000人 年的工作量，最多時(shí)有 1000人投入開發(fā)工作，寫出 100萬行源程序，但發(fā)行的每一新版本都是上一版 1000個(gè)錯(cuò)誤的修正。最后無法逃脫滅頂?shù)臑?zāi)難。 它綜合應(yīng)用計(jì)算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開發(fā)軟件的工程。 14 軟件工程的 目標(biāo) ? 能按時(shí)完成開發(fā)任務(wù) ， 及時(shí)交付使用； ? 付出較低的開發(fā)成本 ， 達(dá)到要求的軟件功能； ? 取得較好的軟件性能； ? 開發(fā)的軟件易于移植； ? 需要較低的維護(hù)費(fèi)用； ? 開發(fā)的軟件可靠性高 。如怎樣定項(xiàng)目計(jì)劃、怎樣實(shí)施需求分析、如何測(cè)試等。如軟件開發(fā)工具、測(cè)試工具等。 將軟件工程劃分為若干階段，分配方法和工具，定義每個(gè)階段的先后順序和完成標(biāo)志。是指從形成開發(fā)軟件概念起 ， 所開發(fā)的軟件使用以后 ， 直到失去使用價(jià)值消亡為止的整個(gè)過程 。 每個(gè)階段有明確的任務(wù) ， 這樣使規(guī)模大 、 結(jié)構(gòu)復(fù)雜和管理復(fù)雜的軟件開發(fā)變得容易控制和管理 。 分析員進(jìn)行簡(jiǎn)要的需求分析 ， 抽象出邏輯結(jié)構(gòu) ， 建立邏輯模型 。 ? 過程 22 一、軟件計(jì)劃與可行性研究 對(duì)每種解決方法 ， 可從以下三個(gè)方面分析研究每種解決方法的可行性 。 資源：已有的或可以獲得的硬件 、 軟件資源 現(xiàn)有技術(shù)人員的技術(shù)水平 已有的工作基礎(chǔ) 。 ?采用不成熟的技術(shù)可能造成技術(shù)風(fēng)險(xiǎn) ?人員流動(dòng)可能給項(xiàng)目帶來風(fēng)險(xiǎn) ?成本和人員估算不合理造成的預(yù)算風(fēng)險(xiǎn) 風(fēng)險(xiǎn)分析的目的是找出風(fēng)險(xiǎn)，評(píng)價(jià)風(fēng)險(xiǎn)的大小，并有效地控制和緩解風(fēng)險(xiǎn)。 例如，有一支開發(fā)過類似項(xiàng)目的開發(fā)和管理的團(tuán)隊(duì)，或者開發(fā)人員比較熟悉系統(tǒng)所處的領(lǐng)域，并有足夠的人員保證，所需的硬件和支撐軟件能通過合法的手段獲取，那么從技術(shù)角度看，可以認(rèn)為具備設(shè)計(jì)和實(shí)現(xiàn)系統(tǒng)的條件。 在技術(shù)分析過程中，分析員 收集系統(tǒng)的性能、可靠性、可維護(hù)性和生產(chǎn)率方面的信息， 分析實(shí)現(xiàn)系統(tǒng)功能、性能所需的技術(shù)、方法、算法或過程 ，從技術(shù)角度分析可能存在的風(fēng)險(xiǎn)，以及這些技術(shù)問題對(duì)成本的影響。 ?社會(huì)效益 ?使用基于計(jì)算機(jī)的系統(tǒng)后對(duì)社會(huì)產(chǎn)生的影響（如提高了辦事效益，使用戶滿意等），通常社會(huì)效益只能定性地估計(jì)。 經(jīng)濟(jì)效益通?？捎秘泿诺臅r(shí)間價(jià)值、投資回收期和純收入來度量。 niFP )1/( ?? niPF )1( ??31 ? 投資回收期 ： 累計(jì)的經(jīng)濟(jì)效益正好等于投資數(shù)（成本）所需的時(shí)間 ? 純收入 ：累計(jì)經(jīng)濟(jì)效益 – 投資數(shù) ? 當(dāng)純收入大于零時(shí)，該工程值得投資開發(fā) ? 當(dāng)純收入小于零時(shí)，該工程不值得投資（除非它有明顯的社會(huì)效益） ? 當(dāng)純收入等于零時(shí)，通常也不值得投資 顯然，純收入越大越好 32 軟件可行性研究 3． 社會(huì)可行性 要開發(fā)的項(xiàng)目是否存在任何侵犯 、 妨礙等責(zé)任問題 ? 要開發(fā)項(xiàng)目的運(yùn)行方式在用戶組織內(nèi)是否行得通 ? 現(xiàn)有管理制度 、 人員素質(zhì) 、 操作方式是否可行 ? ? 三個(gè)方面的可行性 33 中華人民共和國(guó)著作權(quán)法 計(jì)算機(jī)軟件保護(hù)條例 保密法 等 34 可行性分析的結(jié)論 ? 可以立即開始進(jìn)行 ? 需要推遲到某些條件 （ 例如資金 、 人力 、 設(shè)備等 ）落實(shí)之后才能開始進(jìn)行 ? 需要對(duì)開發(fā)目標(biāo)進(jìn)行某些修改之后才能開始進(jìn)行 ? 因?yàn)槟撤N原因 （ 如 ， 技術(shù)不成熟 、 經(jīng)濟(jì)上不合算等） 不能進(jìn)行 35 軟件可行性研究 1． 復(fù)查項(xiàng)目規(guī)模和目標(biāo) 2． 研究正在使用的系統(tǒng) 3． 得到新系統(tǒng)的概括的邏輯模型 4． 導(dǎo)出和評(píng)價(jià)各種方案 5． 推薦可行的方案 6． 編寫可行性研究報(bào)告 ? 可行性研究的具體步驟 36 軟件可行性研究 ? 可行性研究報(bào)告內(nèi)容 1． 引言 。 3． 對(duì)現(xiàn)有系統(tǒng)的分析 。 5． 所建議系統(tǒng)的經(jīng)濟(jì)可行性分析 。 7． 其他可供選擇方案 。 37 二、 軟件系統(tǒng)需求分析 1. 需求分析概念 2. 需求分析的基本任務(wù) 3. 結(jié)構(gòu)化分析方法 BDS 38 數(shù)據(jù)庫建設(shè)的基本規(guī)律 三分 技術(shù)， 七分 管理， 十二分 基礎(chǔ)數(shù)據(jù) 管理 ?數(shù)據(jù)庫建設(shè)項(xiàng)目管理 ?企業(yè)（即應(yīng)用部門）的業(yè)務(wù)管理 基礎(chǔ)數(shù)據(jù) ?收集、入庫 ?更新新的數(shù)據(jù) 39 二、 軟件系統(tǒng)需求分析 1. 需求分析概念 2. 需求分析的基本任務(wù) 3. 結(jié)構(gòu)化分析方法 40 需求的定義 ? IEEE Standard Glossary of Software Engineering Terminology ?用戶解決一個(gè)問題或達(dá)到一個(gè)目標(biāo)所需要的一種狀況或能力 ?系統(tǒng)為了滿足一種約定、標(biāo)準(zhǔn)、規(guī)格說明或其它正式文件而必須滿足或擁有的一種狀況或能力 ?以上兩種狀態(tài)或能力的文檔化表示 主觀需求 客觀需求 需求文檔 41 功能性需求和非功能性需求 ? 功能性需求 ?系統(tǒng)需要提供的服務(wù)或功能：如圖書檢索 ?系統(tǒng)對(duì)特定輸入的處理方式：如對(duì)非法輸入的提示 ?系統(tǒng)在特定環(huán)境下的行為：如長(zhǎng)時(shí)間無操作時(shí)的屏保 ? 非功能性需求 ?對(duì)系統(tǒng)功能或服務(wù)附加的質(zhì)量約束，例如響應(yīng)時(shí)間、容錯(cuò)性、安全性等 —— 客戶所關(guān)心的 (外部質(zhì)量 ) ?從系統(tǒng)開發(fā)和維護(hù)角度出發(fā)的質(zhì)量屬性，例如可理解性、可擴(kuò)展性、可配置性等 —— 軟件開發(fā)或維護(hù)者所關(guān)心的 (內(nèi)部質(zhì)量、軟件所特有 ) 42 二、 軟件系統(tǒng)需求分析 是指開發(fā)人員要準(zhǔn)確理解用戶的要求 ， 進(jìn)行細(xì)致的調(diào)查分析 ， 將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義 ， 再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約 （ 需求規(guī)格說明 ） 的過程 。 回答系統(tǒng)必須 “ 做什么 ” 的問題 。 包括：功能需求、性能需求、環(huán)境需求和用戶界面需求。 2. 需求分析的基本任務(wù) 44 （ 2）分析與綜合，導(dǎo)出軟件的邏輯模型。 包括：對(duì)數(shù)據(jù)域進(jìn)行分解，并分配到各個(gè)子功能上，以確定系統(tǒng)的構(gòu)成及主要成分，并用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。 文檔：需求規(guī)格說明書 初步用戶使用手冊(cè) 確認(rèn)測(cè)試計(jì)劃 2. 需求分析的基本任務(wù) 45 3. 結(jié)構(gòu)化分析方法 SA方法 利用圖形等半形式化的描述方式表達(dá)需求 ， 用它們形成需求說明書中的主要部分 。 SA是一種建?；顒?dòng) ， 該方法使用簡(jiǎn)單易讀符號(hào) ， 根據(jù) 軟件內(nèi)部數(shù)據(jù)傳遞 、 變換的關(guān)系 ， 自頂向下逐層分解 ， 描繪出滿足功能需求的軟件模型 。 數(shù)據(jù)流圖的作用： ?需求分析時(shí)，作為自頂向下的工具 ?描述系統(tǒng)組成部分 ?為技術(shù)員、用戶間交流提供有力方法 47 3. 結(jié)構(gòu)化分析方法 （ 1） 數(shù)據(jù)流圖 （ DFD） 數(shù)據(jù)流圖由數(shù)據(jù)流 、 加工 （ 又稱為數(shù)據(jù)處理 ）、 數(shù)據(jù)存儲(chǔ) （ 又稱為文件 ） 、 數(shù)據(jù)源點(diǎn)或終點(diǎn)四種基本成分組成 。 52 ? 是一種介于自然語言和形式化語言之間的語言 ? 語言的 正文用基本控制結(jié)構(gòu)進(jìn)行分割 ，加工中的 操作用自然語言短語來表示 ? 其基本控制結(jié)構(gòu)有三種： ?簡(jiǎn)單陳述句結(jié)構(gòu) ： 避免復(fù)合語句； ?重復(fù)結(jié)構(gòu) ： while_do 或 repeat_until 結(jié)構(gòu)。有時(shí)侯它比判定表更直觀。 對(duì)數(shù)據(jù)流圖中出現(xiàn)的每一個(gè)數(shù)據(jù)流、文件、加工給出詳細(xì)定義。 數(shù)據(jù)項(xiàng)是組成數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)的最小元素。 主要確定每個(gè)模塊的具體執(zhí)行過程，也稱為過程設(shè)計(jì)。 b. 確定每個(gè)模塊的功能 。 d. 確定模塊之間的接口 ， 即模塊之間傳遞的信息 。 66 （ 1）概要設(shè)計(jì)基本任務(wù) 2) 數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫的設(shè)計(jì)。 b. 對(duì)數(shù)據(jù)庫的設(shè)計(jì)是指數(shù)據(jù)存儲(chǔ)文件的設(shè)計(jì) ，主要進(jìn)行概念設(shè)計(jì) 、 邏輯設(shè)計(jì) 、 物理設(shè)計(jì)三方面設(shè)計(jì) 。 b. 數(shù)據(jù)庫設(shè)計(jì)說明書 。 d. 修訂測(cè)試計(jì)劃 ， 對(duì)測(cè)試策略 、 方法 、 步驟提出明確要求 。 模塊具有以下幾種基本屬性： 接口 、 功能 、 狀態(tài) 、 邏輯 。 模塊化 是指解決一個(gè)復(fù)雜問題時(shí)自頂向下逐層把軟件系統(tǒng)劃分成若干模塊的過程 。 71 （ 2） 概要設(shè)計(jì)的基本原理 2) 抽象 抽象 是指獲取事物本質(zhì)的共同的特性而暫不考慮它的細(xì)節(jié) ， 不考慮其他因素 。 72 （ 2） 概要設(shè)計(jì)的基本原理 3) 抽象信息隱藏 信息隱藏 指在設(shè)計(jì)和確定模塊時(shí) ， 使得一個(gè)模塊內(nèi)包含的信息 （ 過程或數(shù)據(jù) ） ， 對(duì)于不需要這些信息的其他模塊來說 ， 是不能訪問的 。 通過抽象 ， 可以確定組成軟件的過程實(shí)體 。 73 （ 2） 概要設(shè)計(jì)的基本原理 4)模塊獨(dú)立性 模塊