1、信息系統監理師教程PPT信息應用系統建設監理課程計劃 ? ? ? ? ? ? 第一講 信息應用系統建設基礎知識 第二講信息應用系統監理工作 第三講準備階段的監理工作 第四講分析設計階段監理 第五講實施階段監理 第六講驗收階段的監理工作第一講 信息應用系統建設基礎知識在本講中您能了解如下知識點：第一章軟件的概念、特點和分類 第二章軟件工程 第三章軟件配置管理 第四章軟件測試 第五章軟件評審 第六章軟件維護 第七章軟件工程標準 第八章軟件開發文檔 第九章軟件工業化生產時代的基礎技術和方法第一章 軟件的概念、特點和分類確立并使用正確的工程原理和方法，以便能 夠經濟地獲得可靠而有效的軟件”。Fried

2、rich I. Bauer軟件的概念軟件是與計算機系統的操作有關的程序、規程、規則及與之 有關的文檔。 軟件是計算機系統中與硬件相互依存的另一部分，它是包括 程序，數據及其相關文檔的完整集合。其中，程序是按事先 設計的功能和性能要求執行的指令序列；數據是使程序能正 常操縱信息的數據結構；文檔是與程序開發，維護和使用有 關的圖文材料。軟件的構成要素1、程序 2、規程 3、規則 4、文檔軟件的特點具有抽象性、嚴密性、“一次性”、智能性、持久性、依賴 性、復雜性、難以度量、易出錯、必須維護、成 本昂貴等特點。 (1) 軟件是一種邏輯實體,具有抽象性。 (2) 對軟件的質量控制：必須著重在軟件開發方面

3、下功夫。 (3) 軟件沒有老化問題：然而它存在退化問題。 (4) 軟件的開發和運行存在：移植的問題。 (5) 軟件的開發方式：手工。 (6) 軟件本身是復雜的：實際問題，程序邏輯結構所決定的。 (7) 軟件成本昂貴：投入大量、復雜、高強度的腦力勞動。源程序、執行程序? 高級語言源程序經編譯后，得到的目標模塊 還需進行連接。連接程序（即Linker）找出需 要連接的外部模塊并到模塊庫中找出被調用 的模塊，調入內存并連接到目標模塊上，形 成可執行程序。源程序 .C目標程序 可執行程序 .obj 連接 .exe 編譯 執行結果軟件的分類方法按軟件的功能進行劃分： 系統軟件 支撐軟件 應用軟件 在信息

4、系統工程建設中，系統軟件和支撐軟件通常為外購軟 件，應用軟件通常為承建單位自主開發或分包開發的軟件。 按軟件服務對象的范圍劃分： 項目軟件 產品軟件 按軟件規模進行劃分： 按開發軟件所需的人力、時間以及完成的源程序行數，可確 定六種不同規模的軟件。 按軟件工作方式劃分： 實時處理軟件 分時軟件 交互式軟件 批處理軟件 按使用的頻度進行劃分： 一次使用 較高的使用頻度 按軟件失效的影響進行劃分： 影響不大 影響釀成災難性后果軟件規模的分類 類別 參加人數 研制期限 產品規模(源程序行數) 微型 1 14周 0.5k 小型 中型 大型 1 25 520 16月 12年 23年 45年 510年 1

5、k2k 5k50k 50k100k 1M(=1000k) 1M10M甚大型 1001000 極大型 20005000軟件的分類方法按技術特點的角度進行劃分： 業務軟件：處理日常業務,已成為管理信息系統MIS 科技計算軟件： 注重數值算法的速度和精度。目前轉向多 機協作計算、并行計算、可視計算等 嵌入式(embeded)軟件：使工業產品自動化、智能化 實時(real-time)軟件多用于工業控制系統 個人計算機軟件： 字處理、報表、制圖、多媒體寫作、娛 樂游戲、個人數據庫、個人財務、聯機上網等 人工智能軟件：以非數值算法解題，一般有一知識庫存放知 識和規則。第二章 軟件工程概述? 軟件工程是一類

6、求解軟件的系統工程的派生，軟 件工程是一門交叉性學科。軟件工程這一概念， 主要是針對20世紀60年代“軟件危機”而提出的。 其主要成果有：提出了瀑布模型，開發了一些結 構化程序設計語言、結構化方法等。并且圍繞項 目管理提出了費用估算、文檔復審等方法和工具軟件工廠? 70年代初，自“軟件工廠”這一概念提出以來， 其主要成果有：提出了應用廣泛的面向對象語言 以及相關的面向對象方法。尤其是近幾年來，針 對軟件復用及軟件生產，軟件構件技術以及軟件 質量控制技術、質量保證技術得到了廣泛的應用。軟件工程框架? 軟件工程的框架是由軟件工程目標、軟件工程活 動和軟件工程原則三個方面的內容組成。軟件工程目標由上

7、圖可以看出軟件工程可定義為三元組： 目標，原則，活動 其中目標定義為: 1. 正確性：軟件產品達到預期功能的程度。 2. 可用性：軟件基本結構、實現及文檔為用戶可 用的程度。 3. 開銷適宜性：軟件開發、運行的整個開銷滿足 用戶要求的程度。 這三方面的特性決定了軟件過程、過程模型和工程方 法的選擇。軟件工程原則1. 選取適宜開發范型。對需求定義的易變性， 采用適宜的開發范型予以控制，以保證軟件 產品滿足用戶的要求。 2. 采用合適的設計方法。合適的設計方法有助 于這些特征的實現，以達到軟件工程的目標。 3. 提供高質量的工程支持。在軟件工程中，軟 件工具與環境對軟件過程的支持頗為重要。 4.

8、重視開發過程的管理。當軟件過程得以有效 管理時，才能實現有效的軟件工程。軟件工程活動軟件工程活動是“生產一個最終滿足需求且達到工程目 標的軟件產品所需要的步驟”。主要包括需求、設 計、實現、確認以及支持等5個活動。 1. 需求活動包括問題分析和需求分析。問題分析獲取 需求定義。需求分析生成功能規約。 2. 設計活動一般包括概要設計和詳細設計。概要設計 建立整個軟件體系結構。詳細設計產生程序員可用 的模塊說明。 3. 實現活動CODING AND TESTING。 4. 確認活動貫穿于整個開發過程，實現完成后的確認， 保證最終產品滿足用戶的要求。 5. 支持活動包括修改和完善。維護。軟件工程流程

9、需求:定義問題，即建立系統模型，主要任務包括： 需求獲取需求定義，系統功能的一個正確的陳述 需求規約系統需求規格說明，其主要成分：系統 模型、系統功能的一個精確、系統的描述及需求驗證 。 設計：在需求分析的基礎上，給出系統的軟件解決方案。 1）總體設計： 系統的軟件體系結構 2）詳細設計： 針對總體設計結果，給出每一構件的詳細 描述。 實現：選擇可用的構件或語言，對每一構件進行編碼。 確認：貫穿軟件開發的整個過程，主要任務是：軟件測試。 支持：完善性維護、糾錯性維護。產品開發階段產品開發項目流程開始產品評估階段產品評估項目規劃階段產品開發工作規劃需求訪談系統分析階段 軟件品保階段(一) 軟件設

10、計階段 系統設計 軟件品保階段(二) 程序撰寫 系統分析程序撰寫與單元測試階段整合測試階段 軟件品保階段(三)系統測試統計技術 統計技術應用階段 系統保固維護服務階段 系統維護階段 問題追蹤與矯正階段結束軟件生存周期 ? 軟件生存周期是“從設計軟件產品開始 到軟件產品不能再使用為止的時間周期。 軟件生存周期典型地包括項目計劃階段， 需求階段，設計階段、實現階段、測試 階段、安裝和驗收階段、運行和維護階 段，有時還包括引退階段。軟件項目計劃確定要開發軟件系統的總目標，給出它的功能、性能、 可靠性及接口等方面的要求；根據有關成本與進度 的限制分析項目的可行性，探討解決問題的可能方 案；制定完成開發

11、任務的實施計劃，連同可行性研 究報告，提交管理部門審查。軟件需求分析需求分析和定義方式： 需求明確的：用正式的信息域分析，可用于建立信息流和 信息結構的模型，然后逐漸擴充這些模型成為軟件的 規格說明。 需求非明確：用軟件原型化方法，即建立軟件原型，并由 用戶進行評價，從而確定軟件需求。編寫出軟件需求 說明書及初步的用戶手冊，提交管理機構評審。軟件設計分為概要設計和詳細設計? 概要設計，把已確定了的各項需求轉換成一個相應 的體系結構，以結構設計和數據設計開始，建立程 序的模塊結構，定義接口并建立數據結構。此外， 要使用一些設計準則來判斷軟件的質量。 ? 詳細設計，考慮設計每一個模塊部件的過程描述

12、， 對每個模塊要完成的工作進行具體的描述。編寫設 計說明書，提交評審。保證系統設計“根正苗紅”? 系統設計是把需求轉化為軟件系統的最重要的環節。 系統設計的優劣在根本上決定了軟件系統的質量。 就象“一切帝國主義都是紙老虎”那樣可以斷定 “差的系統設計必定產生差的軟件系統?！彼晕?們要努力保證系統設計“根正苗紅”，把一切左傾、 右傾的設計思潮消滅在萌芽狀態。神氣的軟件設計師? Windows NT的一位系統設計師擁有8輛法拉利跑車， 讓Microsoft公司的一些程序員十分眼紅。但你只 能羨慕而不能憤恨，因為并不是每個程序員都有本 事成為復雜軟件系統的設計師。系統設計要比純粹 的編程困難得多。

13、即便你清楚客戶的需求，卻未必 知道應該設計什么樣的軟件系統既能掙最多的 錢又能讓客戶滿意。程序編碼用一種適當的程序設計語言把軟件設計轉換成計算 機可以接受的程序代碼。應當就風格及清晰性對代 碼進行評審，而且反過來應能直接追溯到詳細設計 描述。軟件測試? 軟件測試的主要任務是發現并排除在軟 件需求分析、設計和實現階段產生的各 種錯誤，以保證交付軟件的質量。 ? 軟件測試目的是“在一定的開發時間和 經費的限制下，通過執行有限個測試過 程，盡可能多的發現軟件中的錯誤。軟件測試? 單元測試檢查每一單獨的模塊部件的功能和性能。 ? 組裝測試提供了構造軟件模塊結構的手段，同時測試其 功能和接口。 ? 確認

14、測試檢查所有的需求是否都得到滿足。 在每一個測試步驟之后，要進行調試，以診斷和糾正軟件 的故障。軟件測試的基本原則1、程序員或程序設計機構不應測試自己設計的程序 2、在設計測試用例時，不僅要確定輸入數據，還要確 定預期的輸出結果 3、在設計測試用例時，不僅要考慮合理的輸入數據， 還要考慮不合理的輸入數據。 4、除了檢查程序是否做了它應當做的事情之外，還應 檢查它是否做了不應當做的事 5、應保留所有的測試用例，以便軟件維護和回歸測試 6、模塊中存在錯誤的概率與已發現的錯誤數成正比 7、嚴格執行測試計劃，排除測試的隨意性例：Outlook溢出? 起源于vCard(一種電子名片) ? Outlook

15、直接打開并運行附件中的vCards 而不提示用戶 ? vCards存儲于.vcf文件中，也是沒有提示 而直接運行的 ? 當vCards的生日字段(BDAY)超過55字符 時，就會出現溢出 ? 對策：應用IE 5.5 sp2運行維護 已交付的軟件投入正式使用，并在運行 過程中進行適當的維護。為改正錯誤， 適應環境變化及功能增強而進行的一系 列修改活動。與軟件維護相關聯的那些 任務依賴于所要實施的維護的類型。軟件開發模型? 軟件開發模型是軟件建設過程的結構框架。 ? 軟件開發的承建單位必須首先制定出適宜的開 發策略和軟件工程模型，以便對要交付的軟件 的開發過程實施有效的控制和管理。監理單位 應該根

16、據承建單位選定的模型制定自己的監理 策略。 ? 承建單位可根據軟件開發項目的具體情況選擇 采用何種開發策略、方法和模型，并要在有關 文檔中（例如在“項目開發計劃”中）對所采 用的軟件工程方法與模型加以說明。瀑布模型規定了各項軟件工程活動,包括:制定開發計劃,進行需求 分析和說明,軟件設計,程序編碼.測試及運行維護,并且 規定了它們自上而下,相互銜接的固定次序,如同瀑布流 水,逐級下落計劃 定義階段 需求分析設計 開 發 階 段編碼 測試維護階段運行.維護瀑布式生存周期模型用戶需要 系統分析 系統規格說明書，可行性分析報告硬件需求分析軟件需求分析軟件規格說明書，軟件項目計劃，初步用戶手冊概要設計

17、概要設計說明書詳細設計設計說明書，測試大綱 模塊測試報告， 源程序文檔編程與測試測 試各種測試報告使用維護退役瀑布模型? 軟件開發的實踐表明，上述各項活動之間并非完全是自上而下， 呈線性圖式。實際情況是，每項開發活動均處于一個質量環（輸 入-處理-輸出-評審）中。只有當其工作得到確認，才能繼續進 行下一項活動 ? 瀑布模型的開發策略是要求軟件開發組織在進行軟件開發時，要 嚴格劃分開發過程的每一個階段，并根據工程化的有關規定，在 “軟件開發計劃”及“軟件質量保證計劃”中反映每個階段的活 動。對每階段的工作要進行認真的評審。只有在某個階段的目標 確實達到后，才能進入下一階段的工作。 ? 瀑布模型為

18、軟件開發和軟件維護提供了一種理想情況下的管理模 式，從理論上講，對需求能嚴格地進行預先定義的軟件開發項目 是合適和有效的。然而在軟件工程實踐中，這一開發策略一旦遇 到與假設不相符合的情況，就容易導致失敗。盡管如此，該模型 仍不失為一個很好的基準模型。事實上，在今天的軟件工程實踐 中常常都是以瀑布模型為基礎綜合采用其它各種模型的優點，以 改善軟件開發過程對現實情況的適應性。原型模型原型模型也稱演化模型，此方法主要針對所要開發 的系統的需求不是很清楚， 需要一個可實際運行的工作演示系統，即原型，作 為軟件開發人員和用戶學習、 研究、試驗和確定軟件需求的工作平臺。 原型模型又可細分為增量模型和漸進模

19、型。原型化開發方法步驟1. 2. 3. 4. 5. 6. 7. 8. 9. 快速分析?？焖俅_定軟件系統的基本要求。 構造原型。盡快實現一個可運行的系統。 運行和評價原型。驗證原型的正確程度，根據用戶的新設想，提 出全面的修改意見。 修正和改進。首先修改并確定需求規格說明，然后再重新構造或 修改原型。 判定原型是否完成。如果用戶認可，迭代過程可以結束。否則， 繼續迭代。 判斷原型細部是否說明。 原型細部的說明。 判定原型效果。 整理原型和提供文檔。增量模型對于需求不能很快全部明確的系統，軟件開發項目難于 做到一次開發成功，可使用此模型。此時，應盡可能明 確已知的軟件需求，完成相應的需求分析，并按

20、瀑布模 型的方法進行第一次開發工作。在系統集成時，通過實 驗找出需求中的欠缺和不足之處，明確那些未知的軟件 需求，再迭代進行增加部分的需求分析和開發。對有些 系統這種反復可能要進行幾次，但盡可能不要超過兩 次，否則難以控制軟件的結構規模、開發質量和進度。漸進模型此模型主要是針對部分需求盡管明確但一時難以準確進行 定義的系統設計。如：用戶的操作界面等。使用此模型 時，可以先做初步的需求分析，之后立即進行設計和編 碼，隨后與系統進行第一次集成（不作或少作測試）。根 據集成后反映的問題，進一步做更全面的需求分析、設 計、編碼、測試和集成螺旋模型? 對于復雜的大型軟件，開發一個原型往往達不到要求。螺旋

21、模型將 瀑布模型與演化模型結合起來，并且加入兩種模型均忽略了的風險 分析。螺旋模型沿著螺線旋轉，如下圖所示，在笛卡爾坐標的四個 象限上分別表達了四個方面的活動，即： 1. 制定計劃確定軟件目標，選定實施方案，弄清 項目開發的限制條件； 2. 風險分析分析所選方案，考慮如何識別和消除 風險； 3. 實施工程實施軟件開發 4. 客戶評估評價開發工作，提出修正建議。 沿螺線自內向外每旋轉一圈便開發出更為完善的一個新的軟件版本。?螺旋模型螺旋模型螺旋模型? 螺旋模型是軟件開發的高級策略，它 不僅適合結構化方法而且更適合面向 對象方法。它的實施將對軟件開發組 織的工作模式、人員素質、管理和技 術水平產生

22、深遠的影響，是最有前途 的過程模型之一。（適用于產品開發）噴泉模型? 噴泉模型對軟件復用和生存周期中多項開發活動的集 成提供了支持，主要支持面向對象的開發方法?！皣?泉”一詞本身體現了迭代和無間隙特性。系統某個部 分常常重復工作多次，相關功能在每次迭代中隨之加 入演進的系統。所謂無間隙是指在開發活動，即分析、 設計和編碼之間不存在明顯的邊界第三章 軟件配置管理配置管理項在軟件生存周期內所產生的各種管理文檔和技術文檔、源代 碼列表，及其可執行代碼，以及運行所需的各種數據，構成 軟件配置管理項。 配置管理庫 各系統應在其所屬各級中建立下列各庫： ? 開發庫（DL） 通常，開發庫可僅在項目開發組內設

23、立， 并由其負責維護。 ? 受控庫（CL） 通常，受控庫以軟件配置項為單位建立并 維護。 ? 產品庫（PL 通常，產品庫可在系統、子系統級上設立 并維護。 各類庫中應存放哪些軟件成分，應視所開發軟件的實際情況 酌定。第三章 軟件配置管理質量要求軟件配置管理項是該軟件的真正實質性材料，因此必須保持正確性、完備性和可 追蹤性；任何軟件配置管理項都必須做到“文實相符、文文一致”。以滿足“有 效性”、“可見性”和“可控性”要求。管理規程? ? 軟件配置項不論大小都必須實施軟件配置管理。但所管軟件實體的多少，實施控制的 方式和投入人力多少則與軟件配置項的規模等級、安全性關鍵等級，以及風險大小有 關。必須

24、指出，對于安全性關鍵等級為A、B級的軟件配置項的管理必須從嚴。 每個計算機系統均應制定軟件配置管理規程，至少應明確規定： 1. 各級、各庫中所管的軟件實體的清單； 2. 保證安全性、可靠性、保密性、正確性、完備性、一致性和可追蹤性的具體措 施； 3. 入庫控制辦法和審批手續； 4. 出庫條件及其必備的手續； 5. 變更控制辦法和審批手續。工具 為了嚴格、有效地實施軟件配置管理，承建單位應使用軟件配置管理工具，以滿 足上述質量要求。（VSS）第四章 軟件測試測試目的: 1. 通過測試，發現軟件錯誤； 2. 驗證軟件是否滿足軟件需求規格說明和軟件設計 所規定的功能、性能及其軟件質量特性的要求； 3

25、. 為軟件質量的評價提供依據。 軟件測試技術: 雖然軟件測試技術在不斷地發展，但傳統的 分類方法仍然適用。按使用的測試技術不同 可以將測試分為: 1. 靜態測試:靜態分析和代碼審查 2. 動態測試:白盒測試和黑盒測試。軟件測試方式? 靜態分析主要對程序進行控制流分析、數據流分析、接 口分析和表達式分析等。靜態分析一般由計算機輔助完 成。目前具備靜態分析功能的軟件測試工具有很多。 ? 白盒測試是一種按照程序內部的邏輯結構和編碼結構設 計并執行測試用例的測試方法。根據覆蓋準則使程序中 的每個語句、每個條件分支、每個控制路徑都在程序測 試中受到檢驗。主要以LOG。 ? 黑盒測試是一種著重于驗證軟件功

26、能和性能的正確性， 它的典型測試項目包括功能測試、性能測試、邊界測試、 余量測試、強度測試等。軟件測試工作規程? 制定“軟件測試計劃”。 ? 編寫“軟件測試說明”。對各測試用例所需的測試環境、 測試軟件的準備工作給予說明。對于軟件安全性關鍵等 級為A、B級或軟件規模等級為A、B級的軟件，軟件開發 單位必須組織此測試階段的準備就緒評審，以審查測試 用例、環境、測試軟件、測試工具等準備工作是否全面、 到位。 ? 測試用例設計要求：測試用例的設計應包括該測試用例 的測試過程、測試輸入數據、期望測試結果和評價測試 結果的標準等； ? 測試用例的輸入應包括合理的（有效等價類）值、不合 理的（無效等價類）

27、值和邊界值輸入； ? 為每個測試用例規定測試規程，包括運行測試用例的準 備、初始化、中間步驟、前提和約束；軟件測試工作規程? 把全部測試用例寫入“軟件測試說明”。 ? 執行軟件測試。按照“軟件測試計劃”和“軟件測試說明”對軟 件進行測試。在測試過程中，應填寫“軟件測試記錄”。如果發 現軟件問題，應填寫“軟件問題報告單”。測試記錄包括測試的 時間、地點、操作人、參加人、測試輸入數據、期望測試結果、 實際測試結果及測試規程等。 ? 編制“軟件測試報告”。具體的軟件測試工作完成之后，依照 “軟件測試計劃”、“軟件測試說明”、“軟件測試記錄”對測 試結果進行統計、分析和評估，在此基礎上編制“軟件測試報

28、 告”。 ? 修正軟件測試過程中發現的問題。修正軟件問題要有受控措施， 應先填寫“軟件變更變更報告單”，在得到同意的答復之后進行 軟件的修改（包括軟件文檔、程序和數據的全面修改），修改完 成之后，必須進行回歸測試。 ? 軟件測試階段評審：測試階段工作全部完成之后，應組織本測試 階段的評審。在軟件生存周期各階段應開展的軟件測試活動測試組織軟件測試應由獨立于軟件設計開發的人員進行，根據軟 件項目的規模等級和安全性關鍵等級，軟件測試可由不 同機構組織實施。 1. 軟件單元測試由承建單位自行組織，一般由軟件 開發組實施測試。 2. 軟件集成測試由承建單位自行組織，軟件開發組 和軟件測試組聯合實施測試。

29、 3. 軟件確認測試由承建單位自行組織，軟件測試組 實施測試。 4. 系統測試應由業主單位組織，成立聯合測試組 （一般由專家組、業主單位、軟件評測單位、承 建單位等聯合組成測試組）實施測試。軟件問題報告和軟件變更報告承建單位在測試過程中應編制“軟件問 題報告”和“軟件變更報告”， 描述在 配置控制下的軟件或文檔中發現的各種 問題?！败浖栴}報告”和“軟件變更 報告”應描述必需的糾錯工作和解決問 題所進行的各項活動。糾錯工作過程承建單位應建立和實施糾錯工作規程， 以便處理 在配置控制下和按產品合同要求進行軟件開發活動 中發現的問題。糾錯工作規程應遵照軟件配置管 理執行。第五章 軟件評審評審目的

30、軟件評審是為了使軟件開發按軟件工程提出的過程循 序進行，在各研制階段結束 時，檢查該階段的工作是否完成，所提交的軟件階段 產品是否達到了規定的質量 和技術要求，決定是否可以轉入下一階段研制工作。軟件評審內部評審對每個軟件的每個開發階段都要進行；外部 評審在內部評審的基礎上進行。一般情況下，軟 件需求分析、概要設計、確認測試和系統測試 階段應進行外部評審。外部評審的步驟1. 提出評審申請 2. 承建單位在本階段工作完成并通過內部評審后，至少 提前十天提出外部評審申請。同時將評審文檔及資料 交給軟件專家組成員進行審查。 3. 成立評審組織 4. 成立評審委員會。宣布評審委員會的組成成員和參加 審查

31、組的軟件專家組成員。 5. 評審委員會成員一般應包括：? ? ? ? ? 軟件專家組成員（占評審委員會總人數的50% 以上）； 質量管理人員； 科研計劃管理人員； 開發組成員； 業主單位代表。審查組成員組成及要求? ?審查組由軟件專家組成； 參加同一個項目的軟件專家組成員應相對穩定。軟件評審評審結論 評審小組寫出結論提交專家組. 專家組審查結論 專家組審查結論分為：通過和不通過，并以此向評審委員會提出建 議。通過情況下，承建單位對提出的軟件問題要限期修改，修改情 況由軟件專家組負責人同意簽字后可轉入下一階段工作。不通過情 況下，對提出的問題由承建單位重新做工作后，再提出評審申請進 行復審。在復

32、審通過前不能轉入下一階段工作。復審的步驟與外部 評審相同。第六章 軟件維護 軟件維護是軟件產品交付使用后，為糾正錯誤或 改進性能與其他屬性，或使軟件產品適應改變了 的環境而進行的修改活動。軟件維護一般分為糾 錯性維護、適應性維護和完善性維護三種類型。糾錯性維護糾正在開發階段產生而在測試和驗收過程沒有發現的錯誤。其主要 內容包括：1. 2. 3. 4.設計錯誤； 程序錯誤； 數據錯誤； 文檔錯誤。適應性維護為適應軟件運行環境改變而作的修改。環境改變 的主要內容包括： 1. 影響系統的規則或規律的變化； 2. 硬件配置的變化，如機型、終端、外部設 備的改變等； 3. 數據格式或文件結構的改變； 4

33、. 軟件支持環境的改變，如操作系統，編譯 器或實用程序的變化等。軟件維護 ? 完善性維護為擴充功能或改善性能而進行的修改。修改方式有插 入、刪除、擴充和增強等。主要內容包括： 1. 為擴充和增強功能而作的修改，如擴充解題范圍 和算法優化等； 2. 為改善性能而作的修改，如提高運行速度、節省 存貯空間等； 3. 為便于維護而作的修改，如為了改進易讀性而增 加一些注釋等。第七章 軟件工程標準在開發一個軟件時，需要有許多層次、不同分工的人員 相互配合；在開發項目的各個部分以及各開發階段之間 也都存在著許多聯系和銜接問題。如何把這些錯綜復雜 的關系協調好，需要有一系列統一的約束和規定。在軟 件開發項目

34、取得階段成果或最后完成時，還需要進行階 段評審和驗收測試。投入運行的軟件，其維護工作中遇 到的問題又與開發工作有著密切的關系。軟件的管理工 作則滲透到軟件生存期的每一個環節。所有這些都要求 提供統一的行為規范和衡量準則，使得各種工作都能有 章可循。與軟件相關的各種標準（1）網絡協議：ISO/OSI vs TCP/IP （2）軟件構件：CORBA vs COM （3）建模語言：UML （4）數據訪問：ODBC/JDBC （5）工程管理：CMM vs ISO（9001-3，15504）軟件工程標準的層次根據軟件工程標準制定的機構和標準適用 的范圍有所不同，它可分為五個級別，即 國際標準、國家標準、

35、行業標準、企業(機 構)標準及項目(課題)標準。以下分別對五 級標準的標識符和標準制定(或批準)的 機構做一簡要說明：國際標準由國際聯合機構制定和公布，提供各國參考的標準。如 ISO(International Standards Organization)國際標準化組織。 這一國際機構有著廣泛的代表性和權威性，它所公布的標準也 有較大的影。1960年代初，該機構建立了“計算機與信息處理 技術委員會”, 簡稱ISOTC97，專門負責與計算機有關的標準 化工作。這一標準通常冠有ISO字樣，如ISO 8631 86 Information processingprogram constructs

36、and conventions for their representation信息處理程序 構造及其表示法的約定。該標準現已由中國收入國家標準。國家標準由政府或國家級的機構制定或批準，適用于全國 范圍的標準，如： GB中華人民共和國國家技術監督局是中國的 最高標準化機構，它所公布實施的標準簡稱為 “國標”?，F已批準了若干個軟件工程標準。行業標準由行業機構、學術團體或國防機構制定，并適 用于某個業務領域的標準，如： IEEE(Institute of Electrical and Electronics Engineers)美國電氣與電 子工程師學會。近年該學會專門成立了軟件標準分技術 委員會

37、(SESS)，積極開展了軟件標準化活動，取得了顯 著成果，受到了軟件界的關注。IEEE通過的標準經常要 報請ANSI審批，使之具有國家標準的性質。軟件工程的國家標準1983年5月中國原國家標準總局和原電子工業部主持成立了“計算機 與信息技術標準化技術委員會”，下設十三個分技術委員會。與軟 件相關的程序設計語言分委員會和軟件工程技術分委員會。中國制 定和推行標準化工作的總原則是向國際標準靠攏，對于能夠在中國 適用的標準一律按等同采用的方法，以促進國際交流。這里，等同 采用是要使自己的標準與國際標準的技術內容完全相同，僅稍做編 輯性修改。 從1983年起到現在，中國已陸續制定和發布了20項國家標準

38、。這些 標準可分為4類： 1. 基礎標準； 2. 開發標準； 3. 文檔標準； 4. 管理標準。軟件工程標準第八章 軟件開發文檔文檔的種類GB 8567-88 計算機軟件產品開發文件編制指南中規定，在軟件的開發 過程中，一般地說，應該產生十四種文件。這十四種文件是： 1. 可行性研究報告； 2. 項目開發計劃； 3. 軟件需求說明書； 4. 數據要求說明書； 5. 概要設計說明書； 6. 詳細設計說明書； 7. 數據庫設計說明書； 8. 用戶手冊； 9. 操作手冊； 10. 模塊開發卷宗； 11. 測試計劃； 12. 測試分析報告； 13. 開發進度月報； 14. 項目開發總結報告。文檔的作用

39、（1）提高軟件開發過程的可見性 （2）提高開發效率 （3）可作為開發人員在一定階段內的工作成果和結束標志 （4）記錄開發過程中的有關技術信息，以便協調以后的軟件開發、 使用和維護 （5）提供有關軟件運行、維護和培訓的信息 （6）便于潛在用戶了解軟件的功能、性能等各項指標軟件開發文檔第九章 軟件工業化生產時代的基礎技術和方法? CMM軟件過程成熟度模型概要 ? 個體軟件過程PSP ? 群組軟件過程TSP ? 面向對象的軟件開發方法 ? 可視化開發方法 ? 軟件復用技術CMM軟件過程成熟度模型概要? CMM是Capability Maturity Model的英文單詞的第一 字母縮寫，中文稱：軟件

40、能力成熟度模型。 ? 發展史 1986年美國政府委托卡內基梅隆大學軟件工程研究 所（SEI）開發一套評估軟件承包商能力的方法。 1987年9月發布了一套軟件過程成熟度框架。 1991年SEI將這套框架發展成為軟件成熟度模型， 簡稱CMM，定義為CMM1.1版。 1997年11月SEI完成CMM2.0版，1999年發布。 ? CMM將能力成熟度模型分為5個級別CMM的5個級別? CMM1：初始級 企業一般不具備穩定的軟件開發與維護的環境，軟件項目的 成功取決于某些個人的技能和經驗。 ? CMM2：可重復級 建立了基本的軟件項目管理過程規范。項目經理可以基于過 往的項目的經驗來計劃與管理新的項目。

41、 ? CMM3：定義級 已經將管理和開發兩方面的過程文檔化、并綜合成為企業機 構的標準軟件過程。公司所有項目都可以通過裁減機構的標 準軟件過程而建立適合于本項目的過程規范。 ? CMM4：定量管理級 企業對產品與過程建立起定量的質量目標，同時在過程中加 入規定得很清楚的連續的度量。作為企業的度量方案， 要對 所有項目的重要的過程活動進行生產率和質量的度量。 ? CMM5：優化級 整個企業將會把重點放在對過程進行不斷的優化。企業會采 取主動去找出過程的弱點與長處，以達到預防缺陷 的目標。 同時，分析有關過程的有效性的資料，作出對新技術的 成本 與收益的分析，以及提出對過程進行修改的建議。CMM軟

42、件過程成熟度模型概要? 在介紹CMM內容之前，首先概述一下不成熟軟件組織與成熟軟件組 織的差異。在不成熟的軟件單位，軟件過程一般由實踐者及其管 理者在項目進程中臨時拼湊而成，因而推遲進度和超出預算已成 為慣例，產品質量難以預測，有時為了滿足進度要求，常在產品 功能和質量上做出讓步。 ? 然而，一個成熟軟件組織具有在全組織范圍內管理軟件、開發過 程和維護過程的能力，規定的軟件過程被正確無誤地通知到所有 員工，工作活動均按照已規劃的過程進行。并通過可控的先導性 試驗和費效分析使這些過程得到改進，對已定義過程中的所有崗 位及其職責都有清楚的描述，和通過文檔與培訓使全組織有關人 員對已定義的軟件過程都

43、有很好的理解，從而使其軟件過程所導 致的生產率和質量能隨時間的推移得到改進。 ? 下表給出了不成熟和成熟軟件組織的比較，這種比較分析不僅是 形成軟件能力成熟模型的基礎，也有利于理解該模型。CMM軟件過程成熟度模型概要CMM軟件過程成熟度模型概要? CMM的一些基本概念（1）軟件過程：人們用于開發和維護軟件及其相關過程的一系列活動，包括軟件工程活 動和軟件管理活動。 （2）軟件過程能力：描述（開發組織或項目組）遵循其軟件過程能夠實現預期結果的程 度，它既可對整個軟件開發組織而言，也可對一個軟件項目而言。 （3）軟件過程性能：表示（開發組織或項目組）遵循其軟件過程所得到的實際結果，軟 件過程性能描

44、述的是已得到的實際結果，而軟件過程能力則描述的是最可能的預期 結果，它既可對整個軟件開發組織而言，也可對一個特定項目而言。 （4）軟件過程成熟：一個特定軟件過程被明確和有效地定義，管理測量和控制的程度。 （5）軟件能力成熟度等級：軟件開發組織在走向成熟的途中幾個具有明確定義的表示軟 件過程能力成熟度的平臺。 （6）關鍵過程域：每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程 域，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成 熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目 標不起關鍵作用。歸納為：互相關聯的若干軟件實踐活動和有關基礎設

45、施的一個集 合。 （7）關鍵實踐：對關鍵過程域的實踐起關鍵作用的方針、規程、措施、活動以及相關基 礎設施的建立。關鍵實踐一般只描述“做什么”而不強制規定“如何做”。整個軟 件過程的改進是基于許多小的、漸進的步驟，而不是通過一次革命性的創新來實現 的，這些小的漸進步驟就是通過一些關鍵實踐來實現。 （8）軟件能力成熟度模型：隨著軟件組織定義、實施、測量、控制和改進其軟件過程， 軟件組織的能力也伴隨著這些階段逐步前進，完成對軟件組織進化階段的描述模型。CMM軟件過程成熟度模型概要1.2.軟件開發的風險之所以大，是由于軟件過程能力低，其中最關鍵的 問題在于軟件開發組織不能很好地管理其軟件過程，從而使一

46、些好 的開發方法和技術起不到預期的作用。而且項目的成功也是通過工 作組的杰出努力，所以僅僅建立在可得到特定人員上的成功不能為 全組織的生產和質量的長期提高打下基礎，必須在建立有效的軟件 工程實踐和管理實踐的基礎設施方面，堅持不懈地努力，才能不斷 改進，才能持續地成功。 CMM提供了一個框架，將軟件過程改進的進化步驟組織成5個成熟等 級，為過程不斷改進奠定了循序漸進的基礎。這5個成熟度等級定義 了一個有序的尺度，用來測量一個組織的軟件過程成熟和評價其軟 件過程能力，這些等級還能幫助組織自己對其改進工作排出優先次 序。成熟度等級是已得到確切定義的，也是在向成熟軟件組織前進 途中的平臺。每一個成熟度

47、等級為連續改進提供一個臺基。每一等 級包含一組過程目標，通過實施相應的一組關鍵過程域達到這一組 過程目標，當目標滿足時，能使軟件過程的一個重要成分穩定。每 達到成熟框架的一個等級，就建立起軟件過程的一個相應成分，導 致組織能力一定程度的增大。CMM模型概要 過程能力等級 特點 關鍵過程域第一級 初始級軟件過程是無序的,有時甚至是混亂的, 對過程幾乎沒有定義,成功取決與個人 努力;管理是反應式(消防式)第二級 可重復級建立了基本的項目管理過程來跟蹤費用, 進度和功能特性.制定了必要的過程紀 律,能重復早先類似應用項目取得成功需求管理 軟件項目計劃 軟件項目跟蹤和監督 軟件子合同管理 軟件質量保證

48、 軟件配置管理 組織過程定義 組織過程焦點 培訓大綱 集成軟件管理 軟件產品工程 組織協調 同行專家評審第三級 已定義級已將軟件管理和工程文檔化,標準化, 并綜合成該組織的標準軟件過程;所 有項目均使用經批準,裁減的標準軟 件過程來開發和維護軟件第四級 已定量管理級收集對軟件過程和產品質量的詳細度量, 對軟件過程和產品都有定量的理解與控制定量的過程管理 軟件質量的管理第五級 優化級過程的量化反饋和先進思想,新技術促進 過程不斷改進缺陷預防 技術變更管理 過程變更管理CMM軟件過程成熟度模型概要1） CMM 的結構CMM 結構圖CMM軟件過程成熟度模型概要個體軟件過程PSP個體軟件過程（Pers

49、onal Software Process ,PSP）是由美國Carnegie Mellon大 學軟件工程研究所(CMU/SEI)的Watts s. Humphrey領導開發的，于1995年推出，在 軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個 標志。PSP是一種可用于控制、管理和改進個人工作方式的自我改善過程，是一個 包括軟件開發表格、指南和規程的結構化框架。 PSP為基于個體和小型群組軟件過 程的優化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其 他人相互協作等等。在軟件設計階段， PSP的著眼點在于軟件缺陷的預防，其具體 辦法是強化設計結束準

50、則，而不是設計方法的選擇。根據對參加培訓的104位軟件 人員的統計數據表明，在應用了PSP后，軟件中總的差錯減少了58.0，在測試階 段發現的差錯減少了71.0，生產效率提高了20.0。PSP的研究結果還表明，絕 大多數軟件缺陷是由于對問題的錯誤理解或簡單的失誤所造成的，只有很少一部分 是由于技術問題而產生的。而且根據多年來的軟件工程統計數據表明，如果在設計 階段注入一個差錯，則這個差錯在編碼階段引發了3一5個新的缺陷，要修復這些缺 陷所花的費用要比修復這個設計缺陷所花的費用多一個數量級。因此，PSP保障軟 件產品質量的一個重要途徑是提高設計質量。個體軟件過程PSP1） 個體軟件過程 PSP

51、的演化PSP3 循環開發PSP2 代碼評審 設計評審 PSP1.1 PSP1軟件規模估計 測試報告PSP2.1 設計模板任務規劃 進度安排PSP0當前軟件過程 工作時間記錄 程序缺陷記錄 缺陷類型標準PSP0.1編碼標準 軟件規模度量 過程改善建議個體軟件過程PSP?1.個體軟件過程PSP的內容PSP與具體的技術（程序設計語言、工具或者設計方法）相對獨立，其原則能夠應 用到幾乎任何的軟件工程任務之中。PSP能夠： (1) 說明個體軟件過程的原則； (2) 幫助軟件工程師作出準確的計劃； (3) 確定軟件工程師為改善產品質量要采取的步驟； (4) 建立度量個體軟件過程改善的基準； (5) 確定過

52、程的改變對軟件工程師能力的影響。 個體軟件過程PSP的作用 使用自底向上的方法來改進過程，向每個軟件工程師表明過程改進的原則，使他 們能夠明白如何有效地生產出高質量的軟件。 為基于個體和小型群組軟件過程的優化提供了具體而有效的途徑。其研究與實踐 填補了CMM的空白。 幫助軟件工程師在個人的基礎上運用過程的原則，借助于PSP提供的一些度量和分 析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作的 評估、計劃和預測更加準確、更加有效，進而改進個人的工作表現，提高個人的 工作質量和產量，積極而有效地參與高級管理人員和過程人員推動的組織范圍的 軟件工程過程改進。2. 3. 4. 5.

53、群組軟件過程TSP? ? 致力于開發高質量的產品，建立、管理和授權項目小組，并且指 導他們如何在滿足計劃費用的前提下，在承諾的期限范圍內，不 斷生產并交付高質量的產品。 TSP指導項目組中的成員如何有效地規劃和管理所面臨的項目開發 任務，并且告訴管理人員如何指導軟件開發隊伍。始終以最佳狀 態來完成工作。TSP實施集體管理與自己管理自己相結合的原則， 最終目的在于指導開發人員如何在最少的時間內，以預定的費用 生產出高質量的軟件產品，所采用的方法是對群組開發過程的定 義、度量和改進。 1. 實現TSP方法需要具備的條件 2. 需要有高層主管和各級經理的支持，以取得必要的資 源 整個軟件開發小組至少

54、應在CMM的第二級（可重復層）。 全體軟件開發人員必須經過PSP的培訓，并有按TSP工作的愿望和 熱情。 開發小組成員應在2到20個人之間。? ?群組軟件過程TSP? 按TSP原理對開發小組的基本度量要素1. 2. 3. 4. 5. 所編文檔的頁數。 所編代碼的行數。 花費在各開發階段或各開發任務上的時間（以分為單位）。 在各個開發階段中引入和改正的差錯數目。 在各個階段對最終產品增加的價值。 軟件設計時間應大于軟件實現時間。 設計評審時間至少應占一半以上的設計時間。 代碼評審時間至少應占一半以上的代碼編制時間。 在編譯階段發現的差錯不超過10個 在測試階段發現的差錯不超過5個。?度量TSP實

55、施質量的過程質量元素1. 2. 3. 4. 5.CMM、PSP和TSP組成的軟件過程框架CMM、PSP和TSP組成的軟件過程框架? CMM是過程改善的第一步，它提供了評價 組織的能力、識別優先改善需求和追蹤改 善進展的管理方式。企業只有開始CMM改 善后，才能接受需要規劃的事實，認識到 質量的重要性，才能注重對員工經常進行 培訓，合理分配項目人員，并且建立起有 效的項目小組。然而，它實現的成功與否 與組織內部有關人員的積極參加和創造性 活動密不可分。CMM、PSP和TSP組成的軟件過程框架? PSP能夠指導軟件工程師如何保證自己的工作質量，估計 和規劃自身的工作，度量和追蹤個人的表現，管理自身

56、 的軟件過程和產品質量。經過PSP學習和實踐的正規訓練， 軟件工程師們能夠在他們參與的項目工作之中充分運用 PSP，從而有助于CMM目標的實現。 ? TSP結合了CMM的管理方法和PSP的工程技能，通過告訴軟 件工程師如何將個體過程結合進小組軟件過程，并將后 者與組織進而整個管理系統相聯系；通過告訴管理層如 何支持和授權項目小組，堅持高質量的工作，并且依據 數據進行項目的管理，向組織展示如何應用CMM的原則和 PSP的技能去生產高質量的產品。面向對象的軟件開發方法? 面向對象技術是軟件技術的一次革命，在軟件開發史 上具有里程碑的意義。 ? 隨著OOP（面向對象編程）向OOD（面向對象設計）和 OOA（面向對象分析）的發展，最終形成面向對象的 軟件開發方法OMT(Object Modelling Technique）。 這是一種自底向上和自頂向下相結合的方法，而且它 以對象建模為基礎，從而不僅考慮了輸入、輸出數據 結構，實際上也包含了所有對象的數據結構。所以 OMT徹底實現了PAM沒有完全實現的目標。不僅如此， OO技術在需求分析、可維護性和可靠性這三個軟件開 發的關鍵環節和質量指標上