【正文】 標(biāo) –少資源 、 高效益 –在人力投入 、 開(kāi)發(fā)期 、 成本 、 質(zhì)量諸方面求得最佳 ? 風(fēng)險(xiǎn) –需求：不明與變更 –人員流動(dòng) –軟件知識(shí)產(chǎn)權(quán)保護(hù) –不存在絕對(duì)無(wú)缺陷的軟件產(chǎn)品 成功的標(biāo)志 ? 如期完成 ? 預(yù)算內(nèi)完成 ? 達(dá)到質(zhì)量要求 （ 需求和希望 ） 軟件業(yè)與制造業(yè)的差異 |?設(shè)計(jì) ?||? 生產(chǎn) ?|| 運(yùn) 輸 ||倉(cāng) 儲(chǔ) | |功能度 ….. 制造業(yè) 大量 |? 設(shè)計(jì)（開(kāi)發(fā)） ?||? 生產(chǎn) ? || 運(yùn)輸 ||倉(cāng)儲(chǔ) ||功能度 ….. 軟件業(yè) 大量 軟件的特點(diǎn) ? 軟件是一種邏輯實(shí)體 ， 具有抽象性 – 這個(gè)特點(diǎn)使它與其他工程對(duì)象有著明顯的差異 – 人們可以把它記錄在紙上 、 內(nèi)存和磁盤(pán) 、 光盤(pán)上 ， 但卻無(wú)法看到軟件本身的形態(tài) ， 必須通過(guò)觀察 、 分析 、 思考 、 判斷 ， 才能了解它的功能 、 性能等特性 ? 軟件沒(méi)有明顯的制造過(guò)程 – 一旦研制開(kāi)發(fā)成功 ， 就可以大量拷貝同一內(nèi)容的副本 ， 所以對(duì)軟件的質(zhì)量控制 ， 必須著重在軟件開(kāi)發(fā)方面下工夫 ? 軟件在使用過(guò)程中 ， 沒(méi)有磨損 、 老化的問(wèn)題 – 軟件在生存周期后期不會(huì)因?yàn)槟p而老化 ， 但會(huì)為了適應(yīng)硬件 、環(huán)境以及需求的變化而進(jìn)行修改 ， 而這些修改又不可避免地引入錯(cuò)誤 ， 導(dǎo)致軟件失效率升高 ， 從而使得軟件退化 – 當(dāng)修改的成本變得難以接受時(shí) ， 軟件就被拋棄 ? 軟件對(duì)硬件和環(huán)境有著不同程度的依賴(lài)性 – 這導(dǎo)致了軟件移植的問(wèn)題 軟件的特點(diǎn) (cont.) ? 軟件的開(kāi)發(fā)至今尚未完全擺脫手工作坊式的開(kāi)發(fā)方式 ，生產(chǎn)效率低 ? 軟件是復(fù)雜的 ， 而且以后會(huì)更加復(fù)雜 – 軟件是人類(lèi)有史以來(lái)生產(chǎn)的復(fù)雜度最高的工業(yè)產(chǎn)品 – 軟件涉及人類(lèi)社會(huì)的各行各業(yè) 、 方方面面 ， 軟件開(kāi)發(fā)常常涉及其他領(lǐng)域的專(zhuān)門(mén)知識(shí) ， 這對(duì)軟件工程師提出了很高的要求 ? 軟件的成本相當(dāng)昂貴 – 軟件開(kāi)發(fā)需要投入大量 、 高強(qiáng)度的腦力勞動(dòng) ， 成本非常高 ， 風(fēng)險(xiǎn)也大 – 現(xiàn)在軟件的開(kāi)銷(xiāo)已大大超過(guò)了硬件的開(kāi)銷(xiāo) ? 軟件工作牽涉到很多社會(huì)因素 – 許多軟件的開(kāi)發(fā)和運(yùn)行涉及機(jī)構(gòu) 、 體制和管理方式等問(wèn)題 ， 還會(huì)涉及到人們的觀念和心理 – 這些人的因素 ， 常常成為軟件開(kāi)發(fā)的困難所在 ， 直接影響到項(xiàng)目的成敗 軟件危機(jī) (software crisis) ? 軟件危機(jī)是指計(jì)算機(jī)軟件開(kāi)發(fā)和維護(hù)過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題 – 軟件的數(shù)量急劇膨脹 ， 軟件需求日趨復(fù)雜 ， 維護(hù)的難度越來(lái)越大 ， 開(kāi)發(fā)成本令人吃驚地高 ， 而失敗的軟件開(kāi)發(fā)項(xiàng)目卻屢見(jiàn)不鮮 ? 它主要包含兩個(gè)方面的問(wèn)題： – 如何開(kāi)發(fā)軟件 ， 以滿(mǎn)足不斷增長(zhǎng) ， 日趨復(fù)雜的需求 ——軟件產(chǎn)品質(zhì)量低劣 ， 甚至開(kāi)發(fā)過(guò)程就夭折 – 如何維護(hù)數(shù)量不斷膨脹的軟件產(chǎn)品 ——軟件生產(chǎn)率低 ， 不能滿(mǎn)足需要 軟件危機(jī)的表現(xiàn) ? 對(duì)軟件開(kāi)發(fā)成本和進(jìn)度的估計(jì)常常不準(zhǔn)確 ，開(kāi)發(fā)成本超出預(yù)算 ， 實(shí)際進(jìn)度比預(yù)定計(jì)劃一再拖延的現(xiàn)象并不罕見(jiàn) ? 用戶(hù)對(duì) “ 已完成 ” 系統(tǒng)不滿(mǎn)意的現(xiàn)象經(jīng)常發(fā)生 ? 軟件產(chǎn)品的質(zhì)量往往靠不住 ， Bug一大堆 ，Patch一個(gè)接一個(gè) ? 軟件的可維護(hù)程度非常之低 ? 軟件通常沒(méi)有適當(dāng)?shù)奈臋n資料 ? 軟件的成本不斷提高 ? 軟件開(kāi)發(fā)生產(chǎn)率的提高趕不上硬件的發(fā)展和人們需求的增長(zhǎng) 產(chǎn)生軟件危機(jī)的原因 ? 由于軟件本身的特點(diǎn) ， 管理和控制軟件開(kāi)發(fā)過(guò)程相當(dāng)困難 ， 而且軟件維護(hù)較難 – 軟件是一種高智力活動(dòng) ， 由復(fù)雜的邏輯 、 復(fù)雜的運(yùn)算和復(fù)雜的關(guān)聯(lián)等構(gòu)成 ? 由于對(duì)軟件開(kāi)發(fā)與軟件維護(hù)的不正確方法 ， 產(chǎn)生了軟件危機(jī) – 軟件規(guī)模越來(lái)越大 ， 功能越來(lái)越強(qiáng) ， 導(dǎo)致軟件結(jié)構(gòu)非常復(fù)雜 – 忽視軟件開(kāi)發(fā)前期的需求分析 – 開(kāi)發(fā)過(guò)程沒(méi)有統(tǒng)一的 、 規(guī)范的方法論的指導(dǎo) ， 文檔資料不齊全 ， 忽視人與人的交流 – 忽視測(cè)試階段的工作 ， 提交用戶(hù)的軟件質(zhì)量差 – 輕視軟件的維護(hù)；等等 對(duì)軟件看法的轉(zhuǎn)變 ? 早期那些被認(rèn)為是優(yōu)秀的程序常常很難被別人看懂 ， 通篇充滿(mǎn)了程序技巧 ? 現(xiàn)在人們普遍認(rèn)為優(yōu)秀的程序除了功能正確 ， 性能優(yōu)良之外 ， 還應(yīng)該容易看懂、 容易使用 、 容易修改和擴(kuò)充 軟件的定義 ? 軟件 (software)是計(jì)算機(jī)系統(tǒng)中與硬件(hardware)相互依存的另一部分 ， 它包括： –程序 (program)——是按照事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列 –相關(guān)數(shù)據(jù) (data)——是程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu) –說(shuō)明文檔 (document)——是與程序開(kāi)發(fā)維護(hù)和使用有關(guān)的各種圖文資料 軟件工程 (software engineering) ? 提出 – 1968年秋季 ， NATO（ 北約 ） 的科技委員會(huì)召集了近 50名一流的編程人員 、 計(jì)算機(jī)科學(xué)家和工業(yè)界巨頭 ， 討論和制定擺脫 “ 軟件危機(jī) ” 的對(duì)策 。 每條數(shù)據(jù)流表示在這條流水線(xiàn)上有一組由一定成分組成的數(shù)據(jù)流動(dòng) 。 PDL語(yǔ)言 (偽程序設(shè)計(jì)語(yǔ)言 ) ? 偽碼 （ PDL, Program Design Language） 是一種非形式的比較靈活的語(yǔ)言 ， 它用語(yǔ)言的方式描述模塊內(nèi)部的具體算法和內(nèi)語(yǔ)法 ? 外語(yǔ)法應(yīng)當(dāng)符合一般程序設(shè)計(jì)語(yǔ)言常用的程序語(yǔ)句的語(yǔ)法規(guī)則 ? 內(nèi)語(yǔ)法是沒(méi)有定義的 ， 它可以用自然語(yǔ)言的一些簡(jiǎn)潔的句子 ， 短語(yǔ)和通用的數(shù)學(xué)符號(hào) ，來(lái)描述程序應(yīng)執(zhí)行的功能 UML標(biāo)準(zhǔn)建模語(yǔ)言 ? UML是由 Booch， Rumbaugh 和 Jacobson 發(fā)起 ，在 Booch方法 、 OMT方法和 OOSE方法的基礎(chǔ)上 ，集眾家之長(zhǎng) ， 幾經(jīng)修改而成 ? Techniques to improve quality and reduce cost and timetomarket, include – ponent technology – visual programming – patterns – frameworks – also, techniques to manage the plexity of systems as they increase in scope and scale. UML的九種模型 ? 類(lèi)圖 ：展示對(duì)象類(lèi) 、 接口 、 及其相互合作與關(guān)聯(lián) ? 對(duì)象圖 ：展示對(duì)象及其相互之間的關(guān)系 ? 實(shí)現(xiàn)圖： ?構(gòu)件圖 ：描述部件的物理結(jié)構(gòu)以及各部件之間的依賴(lài)關(guān)系； ?配置圖 ：定義系統(tǒng)中軟硬件的物理構(gòu)架 。 – A. 50年代末 B. 60年代初 – C. 60年代末 D. 70年代初 2. 為了解決軟件危機(jī)人們提出了用 （ ）的原理來(lái)設(shè)計(jì)軟件 ， 這就是軟件工程誕生的基礎(chǔ) 。 – A. 模塊說(shuō)明書(shū) B. 框圖 – C. 程序 D. 數(shù)據(jù)流圖 10. 需求分析是由分析員經(jīng)過(guò)了解用戶(hù)的要求 ， 認(rèn)真細(xì)致地調(diào)研 、 分析 ， 最終應(yīng)建立目標(biāo)系統(tǒng)的邏輯模型 ， 并寫(xiě)出 （ ） 。 人們使用 SA方法是可以得到 （ ） ；使用 SD方法可以得到 （ ） ，并可以實(shí)現(xiàn) （ ） ；而使用 Jackson方法可以實(shí)現(xiàn)（ ） 。 – A. 外部特性 B. 內(nèi)部特性 – C. 算法和使用數(shù)據(jù) D. 功能和輸入輸出數(shù)據(jù) 19. 詳細(xì)設(shè)計(jì)的任務(wù)是決定每個(gè)模塊的 （ ） ，即模塊的 （ ） 。 12. ―瀑布模型 ” 將 “ 軟件周期 ” 劃分為（ ） 、 （ ） 、 （ ） 個(gè)周期 。 – A. 詳細(xì)設(shè)計(jì) B. 可行性分析 – C. 運(yùn)行及維護(hù) D. 測(cè)試與排錯(cuò) 4. 軟件測(cè)試中 ， 白盒法是通過(guò)分析程序的 （ ）來(lái)設(shè)計(jì)測(cè)試實(shí)例的方法 ， 黑盒法是根據(jù)程序的 （ ） 來(lái)設(shè)計(jì)測(cè)試實(shí)例的方法 。 ?選擇測(cè)試用例 ， 使得被測(cè)程序能在邊界值及其附近運(yùn)行 ， 從而更有效地暴露程序中潛藏的錯(cuò)誤 。 處理 任務(wù) N PAD圖 (問(wèn)題分析圖 ) ? PAD圖 （ problem analysis diagram） 使用五種基本控制結(jié)構(gòu) – 分支結(jié)構(gòu)由兩部分組成 ， 帶鋸齒的框?yàn)闂l件判斷 ，每一個(gè)鋸齒表示該判定中的一種條件 ， 與該齒連接的處理框表示該分支要執(zhí)行的處理 – 循環(huán)結(jié)構(gòu)也由兩個(gè)部分組成 ， 左邊的一個(gè)框 （ 右邊多一條豎線(xiàn) ） 表示循環(huán)的類(lèi)型和終止條件 ， 右邊的一個(gè)框表示要重復(fù)執(zhí)行的循環(huán)體 ? 任何 PAD圖都是由下述的基本控制模塊構(gòu)成 – 它是一種二維平面圖形 ， 從左向右擴(kuò)展一條豎線(xiàn) – PAD圖中豎線(xiàn)的總條數(shù)就是程序的層次數(shù) PAD圖 (問(wèn)題分析圖 ) while 型條件 循環(huán)體 順序結(jié)構(gòu) 選擇結(jié)構(gòu) dowhile 循環(huán)結(jié)構(gòu) case 結(jié)構(gòu) dountil 循環(huán)結(jié)構(gòu) 任務(wù) 1 任務(wù) 2 任務(wù) N THEN部分 ELSE部分 條件 T F until 型條件 循環(huán)體 任務(wù) 1 任務(wù) 2 任務(wù) n 控制 變量 = 值 1 值 2 值 n 數(shù)據(jù)流圖中以標(biāo)有名字的圓圈代表加工 ， 名字表示加工的含義 ， 指向加工的數(shù)據(jù)流是該加工的輸入數(shù)據(jù) ， 離開(kāi)加工數(shù)據(jù)流是該加工的輸出數(shù)據(jù) 。 ? 軟件工程的定義 – 軟件工程是一門(mén)研究如何用系統(tǒng)化 、 規(guī)范化 、 數(shù)量化等工程原則和方法去進(jìn)行軟件的開(kāi)發(fā)和維護(hù)的學(xué)科 。 如： –瀑布模型 –螺旋模型 –噴泉模型 軟件生存周期方法學(xué) ? 軟件工程采用的生存周期方法學(xué)就是 – 從時(shí)間角度對(duì)軟件開(kāi)發(fā)和維護(hù)的復(fù)雜問(wèn)題進(jìn)行分解 – 將軟件的生存周期分為若干階段 ? 需求定義 ? 軟件設(shè)計(jì) ? 編程 ? 測(cè)試 ? 運(yùn)行維護(hù)等 – 每個(gè)階段有相對(duì)獨(dú)立的任務(wù) ， 便于分工協(xié)作 – 使軟件開(kāi)發(fā)過(guò)程按有秩序能管理的方式組織起來(lái) ，從而降低軟件開(kāi)發(fā)的難度 軟件生命周期的花費(fèi)比例 需求分析設(shè)計(jì)編碼測(cè)試維護(hù) 1 軟件工程的基本概念 ? 軟件工程學(xué)的形成和發(fā)展 ? 軟件工程學(xué)研究的內(nèi)容 ? 軟件與軟件生命周期 ? 軟件工程基本原則 軟件工程基本原則 ? 通用性和指導(dǎo)性 – 軟件工程實(shí)踐總結(jié)出的基本現(xiàn)象 ? 穩(wěn)定性 – 不會(huì)時(shí)時(shí)改變 ， 不依賴(lài)于采用的技術(shù) 、 方法和工具 ? 概括性 – 針對(duì)軟件工程和軟件產(chǎn)品特性的抽象描述 ? 基礎(chǔ)性 – 理解和采用它需有具體的方法和技術(shù)做補(bǔ)充 軟件工程的原則 原則 方法與技術(shù) 方法學(xué) 工具 Principle Method Technique 體現(xiàn)原則的途徑和步驟 Methodology 方法和技術(shù)的組合，支持整個(gè)軟件工程過(guò)程 Tools 支持方法、技術(shù)和方法學(xué)的軟件 一般性原則 ? 嚴(yán)格性與形式化 ? 復(fù)雜性和分解 ? 模塊化 ? 抽象性和細(xì)化 ? 變更預(yù)見(jiàn)性 ? 通用性與復(fù)用性 ? 遞增式 軟件質(zhì)量管理原則 ? 產(chǎn)品質(zhì)量以滿(mǎn)足用戶(hù)需求為最高準(zhǔn)則 ? 質(zhì)量第一 ? 以人為本 ? 質(zhì)量與生產(chǎn)率 ? 質(zhì)量成本 ? 密切與用戶(hù)的聯(lián)系 ? 盡早排除缺陷 ? 實(shí)施過(guò)程質(zhì)量控制 文檔編制原則 ? 在文檔標(biāo)準(zhǔn)基礎(chǔ)上剪裁 ? 注意讀者對(duì)象 ? 便于使用和查找 ? 使用術(shù)語(yǔ) 、 概念不應(yīng)有矛盾 ? 描述的精確性 ， 無(wú)多義性 ? 專(zhuān)職人員與開(kāi)發(fā)人員結(jié)合 ? 獨(dú)立性 需求分析與定義原則 ? 編制需求規(guī)格說(shuō)明以前 ， 必須十分明確要解決的問(wèn)題 ，即應(yīng)先明確需求 ? 真正弄清需求 ， 還應(yīng)包括為什么這樣定義 ? 需求不清必將導(dǎo)致預(yù)算不準(zhǔn) – 總結(jié)產(chǎn)生錯(cuò)誤的原因： ? 需求變更 ， 遺漏重要需求 ， 與用戶(hù)交流不暢 ? 需求分析不充分 ， 需求規(guī)格說(shuō)明質(zhì)量低劣 ? 發(fā)現(xiàn)需求規(guī)格說(shuō)明中有問(wèn)題 ， 應(yīng)立即著手解決 ， 不可將其帶入后續(xù)開(kāi)發(fā)階段 ? 需求規(guī)格說(shuō)明中不應(yīng)含有待確定的部分 ? 進(jìn)行需求分析時(shí)不做設(shè)計(jì) ， 不應(yīng)將需求分析做什么與如何做混淆 設(shè)計(jì)原則 ? 重視需求向設(shè)計(jì)轉(zhuǎn)化工作 ， 必要時(shí)比較多個(gè)設(shè)計(jì)方案 ? 設(shè)計(jì)應(yīng)能和需求對(duì)應(yīng) ， 保證每項(xiàng)需求均在設(shè)計(jì)中得到體現(xiàn) ? 設(shè)計(jì)文檔是設(shè)計(jì)的成果 ， 頭腦中的設(shè)想不是設(shè)計(jì) ? 盡可能復(fù)用一切可復(fù)用的部分 ? 設(shè)計(jì)應(yīng)易于變更 、 易于維護(hù) 、 易于排錯(cuò) ? 優(yōu)秀的設(shè)計(jì)出自?xún)?yōu)秀人才之手 編碼原則 ? 簡(jiǎn)明清晰 ? 盡可能少用 、 甚至不用全局變量 ? 程序執(zhí)行速度不應(yīng)優(yōu)先于正確性的考慮 ? 命名易記 ， 充分注釋 ， 命名唯一 ， 可追溯