1、軟件工程課 名：軟件工程教材： 軟件工程導論 （第四版） 張海藩 清華大學出版社（2003）參考教材： 1 計算機軟件工程規范國家標準匯編(2000) 2 軟件工程實踐者的研究方法 3 軟件工程Java語言實現教學方式：授課 、大作業 課時： 1818軟 件 工 程 實用軟件工程 （第二版） 鄭人杰 殷人昆 陶永雷 清華大學出版社（1996） 軟件工程 -實踐者的研究方法（英文版 第四版） Roger S. Pressman 機械工業出版社參考書目第一章 軟件工程學概述Late 1950s:1.軟件危機 （Software Crisis)In the early days: “Software

2、” = “Place a sequence of instructions together to get the computer to do something useful”.User ComputerComputer became cheaper and more commonHigh level languages were inventedProgrammerUser Computereasier1.軟件危機Early 1960s: Very few large software projects were done by some experts.Middle to late 1

3、960s:Truly large software systems were attempted.例: 美國IBM公司在1963年至1966年開發的IBM360機的操作系統。這一項目花了5000人一年的工作量，最多時有1000人投入開發工作，寫出了近100萬行源程序。.據統計，這個操作系統每次發行的新版本都是從前一版本中找出1000個程序錯誤而修正的結果。.1.軟件危機 這個項目的負責人F. D. Brooks事后總結了他在組織開發過程中的沉痛教訓時說：“.正像一只逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷得越深，最后無法逃脫滅頂的災難。.程序設計工作正像這樣一個泥潭，.一批批程序員被迫在

4、泥潭中拼命掙扎，.誰也沒有料到問題竟會陷入這樣的困境.”。IBM360操作系統的歷史教訓成為軟件開發項目的典型事例為人們所記取。Software Crisis !1.軟件危機 項目沒有被很好地理解；計劃不周，最終導致進度拖延。例1. In the late 1960s, a bright-eyed young engineer* was chosen to “write” a computer program for an automated manufacturing application. The reason for his selection was simple. He was t

5、he only person in his technical group who had attended a computer programming seminar. He knew the ins and outs of assembler language and Fortran, but nothing about software engineering and even less about project scheduling and tracking.*If youre wondering whether this story is autobiographical, it

6、 is!問題出在哪里？1.軟件危機His boss gave him the appropriate manuals and a verbal description of what had to be done. He was informed that the project must be completed in two months.He read the manuals, considered his approach, and began writing code. After two weeks, the boss called him into his office and

7、asked how things were going.“Really great,” said the young engineer with youthful enthusiasm, “This was much simpler than I thought. Im probably close to 75 percent finished.”The boss smiled. “Thats really terrific,” he said. He then told the young engineer to keep up the good work and plan to meet

8、again in a weeks time.1.軟件危機A week later the boss called the engineer into his office and asked, “Where are we?”“Everythings going well,” said the youngster, “but Ive run into a few small snags. Ill get them ironed out and be back on track soon.”“How does the deadline look?” the boss asked.“No probl

9、em,” said the engineer. “Im close to 90 percent complete.”If youve been working in the software world for more than a few years, you can finish the story. Itll come as no surprise that the young engineer stayed 90 percent complete for the entire project duration and only finished (with the help of o

10、thers) one month late.1.軟件危機 沒有充分的文檔資料(documentation) Myth: The only deliverable for a successful project is the working program.Reality: A working program is only one part of a software configuration that includes programs, documents, and data. Documentation forms the foundation for successful deve

11、lopment and, more important, provides guidance for the software maintenance task.VITAL!人與人的交流比寫程序困難得多。Managers evaluate, track progress, .Programmers communicate to each otherMaintainers 1.軟件危機 軟件可靠性(reliability)缺少度量的標準，質量無法保證。 如何保證軟件產品的質量，是非常復雜困難的問題。特別對于規模龐大的軟件，如：.The software supporting the Americ

12、an space shuttle consists of 3 million lines of code, including computers on the ground controlling the launch and the flight; there were one hundred thousand lines of code in the shuttle itself in 1985.Many computer scientists and software engineers continue to believe there is no way to write and

13、test the software to guarantee adequate reliability.1.軟件危機 軟件難以維護(maintainability) 不易升級(evolvability)Myth: Once we write the program and get it to work, our job is done.Reality: Someone once said that “the sooner you begin writing code, the longer itll take you to get done.” Industry data indicate t

14、hat between 50 and 70 percent of all effort expended on a program will be expended after it is delivered to the customer for the first time.1.軟件危機 Better management Different team organizations Better languages & tools Uniform coding conventions 必須意識到：“軟件” 編程，它有自己的生命周期 (life cycle)。大型軟件系統的開發與其它工程項目如

15、建造橋梁、制造飛機、輪船等的開發是同理的。解決問題的想法：1.2 軟件工程1.2.1軟件工程發展歷史“軟件工程” (Software Engineering)術語首次出現：1968年NATO會議軟件工程方法:是采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。Evolution of software 早期 自定義軟件用戶自己開發、自己使用、自己維護19501960Evolution of software 早期 第二階段 多用戶 實時自定義軟件 數據庫 軟件產品 1950196019701980Evolution of

16、 software 早期 第二階段 第三階段 多用戶 分布式系統 實時 嵌入“智能”自定義軟件 數據庫 低成本硬件 軟件產品 消費者的影響 19501960197019801990Evolution of software 早期 第二階段 第三階段 第四階段 多用戶 分布式系統 強大的桌面系統 實時 嵌入“智能” 面向對象技術自定義軟件 數據庫 低成本硬件 專家系統 軟件產品 消費者的影響 人工神經網絡 批處理 并行計算 網格計算195019601970198019902000軟件的特點軟件具有與硬件不同的特點:軟件是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性。軟件是由開發或工程化而

17、形成的，而不是傳統意義上的制造產生的;在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題。大多數軟件是自定義的，而不是通過已有構件組裝的。軟件的開發至今尚未完全擺脫手工藝的開發方式。維護不同。軟件的分類類別參加人員數研制期限產品規模（源程序行數）微型114周0.5k小型116月1k2k中型2512年5k50k大型52023年50k100k甚大型100100045年1M(=1000k)極大型20005000510年1M10M如果按軟件規模進行劃分： 計算機軟件發展的三個時期及其特點 特點時期程序設計程序系統軟件工程軟件所指 程序 程序及說明書 程序, 文檔, 數據主要程序設計語言 匯編及機

18、器語言 高級語言 軟件語言軟件工作范圍 程序編寫 包括設計和測試 軟件生存期軟件使用者 程序設計者本人 少數用戶 市場用戶軟件開發組織 個人 開發小組 開發小組及大中型軟件開發機構軟件規模 小型 中小型 大中小型決定質量的因素 個人編程技術 小組技術水平 技術水平及管理水平開發技術和手段 子程序和程序庫 結構化程序設計 數據庫, 開發工具,開發環境, 工程化開發方法, 標準和規范,網絡及分布式開發,面向對象技術及軟件復用維護責任者 程序設計者 開發小組 專職維護人員硬件特征 價格高, 存儲容量小, 工作可靠性差 降價, 速度、容量及工作可靠性有明顯提高 向超高速, 大容量, 微型化及網絡化方向

19、發展軟件特征 完全不受重視 軟件技術的發展不能滿足需要,出現軟件危機 開發技術有進步, 但未獲突破性進展, 價格高未完全擺脫軟件危機軟件構件軟件構件要求： 標準構件（components） 可復用性（Reusability） 集成化軟件開發環境（ISEE）應用系統 軟件生產過程 軟件生產過程應用構件提取車間 應用構件庫領域 1領域 2應用系統 軟件生產過程應用構件提取車間 應用構件庫構件生產車間領域 1領域 2應用系統12341基礎構件，2功能構件 3接口構件，4用戶界面構件 軟件生產過程應用構件提取車間 應用構件庫構件生產車間 構件庫組裝車間領域 1領域 2應用系統 .12341基礎構件，2

20、功能構件 3接口構件，4用戶界面構件 軟件技術面臨的問題： 軟件復雜性 例:1 Windows95程序超過1000萬行 2 WWMCCS（軍事和控制）花費3500多人拖了幾年，交付后發現出100個錯誤。最后失敗。 3 城市銀行出納機程序7.8萬行，150人年 軟件生產率 OO技術(軟件IC)軟件危機的主要特征軟件開發周期大大超過規定日期;軟件系統開發成本高，周期長，質量差，滿足不了市場需求; 軟件質量無保證軟件系統開發人員數量少，質量低軟件系統維護難度大供不應求：軟件開發生產率跟不上計算機應用的迅速發展 軟件的版權問題得不到保證對軟件開發成本和進度的估計常常很不準確。實際成本比估計成本有可能高

21、出一個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象并不罕見。用戶對“已完成的”軟件系統不滿意的現象經常發生。軟件開發人員常常在對用戶要求只有模糊的了解，甚至對所要解決的問題還沒有確切認識的情況下，就匆忙著手編寫程序。軟件危機的典型表現軟件產品的質量往往靠不住。軟件可靠性和質量保證的確切的定量概念剛剛出現不久，軟件質量保證技術(審查、復審和測試)還沒有堅持不懈地應用到軟件開發的全過程中，這些都導致軟件產品發生質量問題。軟件常常是不可維護的。很多程序中的錯誤是非常難改正的，實際上不可能使這些程序適應新的硬件環境，也不能根據用戶的需要在原有程序中增加一些新的功能。“可重用的軟件”還是一個沒有完

22、全做到的、正在努力追求的目標，人們仍然在重復開發類似的或基本類似的軟件。軟件通常沒有適當的文檔資料。計算機軟件不僅僅是程序，還應該有一整套文檔資料。這些文檔資料應該是在軟件開發過程中產生出來的，而且應該是“最新式的”(即和程序代碼完全一致的)。軟件開發組織的管理人員可以使用這些文檔資料作為“里程碑”，來管理和評價軟件開發工程的進展狀況；軟件開發人員可以利用它們作為通信工具，在軟件開發過程中準確地交流信息；對于軟件維護人員而言，這些文檔資料更是必不可少的。軟件成本在計算機系統總成本中所占的比例逐年上升。由于微電子學技術的進步和生產自動化程度不斷提高，硬件成本逐年下降，然而軟件開發需要大量人力，軟

23、件成本隨著通貨膨脹以及軟件規模和數量的不斷擴大而持續上升。美國在1985年軟件成本大約已占計算機系統總成本的90%。軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。軟件產品“供不應求”的現象使人類不能充分利用現代計算機硬件提供的巨大潛力。硬件/軟件成本變化趨勢硬件軟件開發 軟件維護100% 0%195519701985軟件技術進步落后于需求增長嚴重的問題是，在軟件開發的不同階段進行修改需要付出的代價是很不相同的。引入同一變動付出的代價隨時間變化的趨勢改正一個問題需付出的代價需求分析結構設計詳細設計編碼集成測試系統測試現場改正一個問題的估計費用改正一個問題估計的工作量20200

24、200010005.02.50.050.5(美元)(人天)yet, Success Hasnt Come Easily31%53%16%Successfully（成功）Challenged（異議）Canceled（失敗） 成功的標準：用戶在使用用戶使用軟件很容易做完要做的事 失敗的根本原因： 開發人員寫出的軟件達不到用戶要求： 人的能力問題. 當前技術發展問題 系統平臺問題中國軟件產業：挑戰與機遇 挑戰： 外國軟件打入 軟件侵權行為 軟件開發投資力度不足 軟件人才結構不合理，缺乏高級系統程序員和項目負責人。 軟件人員缺乏軟件工程化的概念。軟件工程 (software engineering)

25、軟件工程是應用計算機科學、數學及管理科學等原理開發軟件的工程。它借鑒傳統工程的原則、方法，以提高質量，降低成本為目的。 軟件工程為了經濟地獲得可靠的和能在實際機器上高效運行的軟件而建立合使用的好的工程原則。 軟件工程 一種層次化技術工具方法過程質量焦點Software engineering layers軟件工程 一種層次化技術質量焦點：支持軟件工程的根基就在于對質量的關注。過程：軟件工程的過程將技術層結合在一起，使計算機軟件合理和及時開發出來。方法：涵蓋一系列的任務：需求分析、設計、編程、測試和維護。工具：對過程、方法提供自動或半自動的支持。例CASE集成軟件、硬件或一個軟件工程數據庫。軟件

26、工程是一門交叉學科軟件開發模型軟件開發方法 軟件立項到終止的全過程 軟件開發工具 軟件開發環境 計算機輔助軟件工程（CASE） 軟件工程管理 軟件工程經濟學？軟件工程的主要研究內容軟件工程項目的基本目標 組織實施軟件工程項目，從技術上和管理上采取了多項措施以后，最終希望得到項目的成功。所謂成功指的是達到以下幾個主要的目標：付出較低的開發成本；達到要求的軟件功能；取得較好的軟件性能；開發的軟件易于移植；需要較低的維護費用；能按時完成開發工作，及時交付使用。軟件工程框架可用性性性確正合算選取適宜的開發模型采用合適的設計方法提供高質量的工程支持重視軟件工程的管理基本過程原則 目標 過 程支持過程組織

27、過程“軟件工程”課程的教學與實踐(1) 立足于系統的整體。(2) 講授系統分析、系統需求、系統設計、系統實現、系統測試及維護的理論和方法。(3) 運用所學軟件和技術構筑一理想的系統。與其他軟件專業課的區別：“軟件工程”課程的教學與實踐 對軟件的認識： 上升 程序 系統 思維定式： 上升 程序員 系統工程師 (系統分析員)系統分析員的地位用戶分析員程序員“一個好的工業，應有一套良好的標準來配套”軟件的工業化生產過程應具備的特點：明確的工作步驟詳細具體的規范化文檔明確的質量評價標準軟件工程技術的兩個明顯特點： 強調規范化 強調文檔化軟件工程目標之間的關系 軟件工程的原則(分解和）抽象：抽取事物最基

28、本的特性和行為，忽略非基本的細節。采用分層次抽象，自頂向下、逐層分解的辦法控制軟件開發過程的復雜性。例如，軟件瀑布模型、結構化分析方法、結構化設計方法，以及面向對象建模技術等都體現了抽象的原則。信息隱蔽：將模塊設計成“黑箱”，實現的細節隱藏在模塊內部，不讓模塊的使用者直接訪問。這就是信息封裝，使用與實現分離的原則。使用者只能通過模塊接口訪問模塊中封裝的數據。模塊化：模塊是程序中邏輯上相對獨立的成分，是獨立的編程單位，應有良好的接口定義。如C語言程序中的函數過程，C+語言程序中的類。模塊化有助于信息隱蔽和抽象，有助于表示復雜的系統。 局部化：要求在一個物理模塊內集中邏輯上相互關聯的計算機資源，保

29、證模塊之間具有松散的耦合，模塊內部具有較強的內聚。這有助于加強模塊的獨立性，控制解的復雜性。確定性：軟件開發過程中所有概念的表達應是確定的、無歧義性的、規范的。這有助于人們之間在交流時不會產生誤解、遺漏，保證整個開發工作協調一致。一致性：整個軟件系統（包括程序、文檔和數據）的各個模塊應使用一致的概念、符號和術語。程序內部接口應保持一致。軟件和硬件、操作系統的接口應保持一致。系統規格說明與系統行為應保持一致。用于形式化規格說明的公理系統應保持一致。完備性：軟件系統不丟失任何重要成分，可以完全實現系統所要求功能的程度。為了保證系統的完備性，在軟件開發和運行過程中需要嚴格的技術評審。可驗證性：開發大

30、型的軟件系統需要對系統自頂向下、逐層分解。系統分解應遵循系統易于檢查、測試、評審的原則，以確保系統的正確性。軟件工程方法學包含3個要素：方法是完成軟件開發的各項任務的技術方法，回答“怎樣做”的問題；工具是為運用方法而提供的自動的或半自動的軟件工程支撐環境；過程是為了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。目前使用得最廣泛的軟件工程方法學：傳統方法學面向對象方法學兩種程序設計方法程序設計的兩次飛躍結構化程序設計程序=數據結構+算法面向對象程序設計程序 = 對象 + 消息 兩類軟件工程方法傳統軟件工程軟件分析 總體設計 詳細設計 面向過程的編碼 測試 面向對象

31、軟件工程軟件分析與對象抽取 對象詳細設計 面向對象的編碼 測試 1. 用分階段的生命周期計劃嚴格管理經統計發現，在不成功的軟件項目中有一半左右是由于計劃不周造成的。應該把軟件生命周期劃分成若干個階段，并相應地制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發與維護工作進行管理。不同層次的管理人員都必須嚴格按照計劃各盡其職地管理軟件開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃。軟件工程的7條基本原理2. 堅持進行階段評審軟件的質量保證工作不能等到編碼階段結束之后再進行。這樣說至少有兩個理由：第一，大部分錯誤是在編碼之前造成的，根據統計，設計錯誤占軟件錯誤的63%，編碼錯誤僅占3

32、7%；第二，錯誤發現與改正得越晚，所需付出的代價也越高。因此，在每個階段都進行嚴格的評審，以便盡早發現在軟件開發過程中所犯的錯誤，是一條必須遵循的重要原則。3. 實行嚴格的產品控制在軟件開發過程中改變需求是難免的，只能依靠科學的產品控制技術來順應這種要求。也就是說，當改變需求時，為了保持軟件各個配置成分的一致性，必須實行嚴格的產品控制，其中主要是實行基準配置管理。所謂基準配置又稱為基線配置，它們是經過階段評審后的軟件配置成分。基準配置管理也稱為變動控制：一切有關修改軟件的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規程進行評審，獲得批準以后才能實施修改。絕對不能誰想修改軟件，就隨意

33、進行修改。4. 采用現代程序設計技術從提出軟件工程的概念開始，人們一直把主要精力用于研究各種新的程序設計技術，并進一步研究各種先進的軟件開發與維護技術。實踐表明，采用先進的技術不僅可以提高軟件開發和維護的效率，而且可以提高軟件產品的質量。5. 結果應能清楚地審查軟件產品不同于一般的物理產品，它是看不見摸不著的邏輯產品。軟件開發人員(或開發小組)的工作進展情況可見性差，難以準確度量，從而使得軟件產品的開發過程比一般產品的開發過程更難于評價和管理。為了提高軟件開發過程的可見性，更好地進行管理，應該根據軟件開發項目的總目標及完成期限，規定開發組織的責任和產品標準，從而使得所得到的結果能夠清楚地審查。

34、6. 開發小組的人員應該少而精軟件開發小組的組成人員的素質應該好，而人數則不宜過多。素質高的人員的開發效率比素質低的人員的開發效率可能高幾倍至幾十倍，而且素質高的人員所開發的軟件中的錯誤明顯少于素質低的人員所開發的軟件中的錯誤。此外，隨著開發小組人員數目的增加，因為交流情況討論問題而造成的通信開銷也急劇增加。當開發小組人員數為N時，可能的通信路徑有N(N-1)/2條，可見隨著人數N的增大，通信開銷將急劇增加。7. 承認不斷改進軟件工程實踐的必要性遵循上述6條基本原理，就能夠按照當代軟件工程基本原理實現軟件的工程化生產，但是，僅有上述6條原理并不能保證軟件開發與維護的過程能趕上時代前進的步伐，能

35、跟上技術的不斷進步。因此，Boehm提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第7條基本原理。按照這條原理，不僅要積極主動地采納新的軟件技術，而且要注意不斷總結經驗。1.3 軟件生存周期 軟件生存周期 (Software Life Cycle)軟件產品或軟件系統從提出、設計、投入使用到被淘汰的全過程。軟件系統開發方法結構化開發方法（瀑布模型）快速原型方法面向對象開發方法方法 1 軟件工程和軟件生命周期 為什么稱為軟件生命周期？軟件生命周期人的生命周期費用效益費用貢獻2軟件生存期的步驟(1)制定計劃(2)需求分析和定義(3)軟件設計(4)程序編寫(5)軟件測試(6)運行/維護軟件生存

36、期的階段劃分(國標計算機軟件開發規范)(1)可行性研究與計劃(2)需求分析(3)總體設計 上游 (4)詳細設計(5)實現(6)集成測試(7)確認測試 下游(8)使用和維護只考慮編寫程序 涉及整個軟件生存周期擴展到軟件工作的范圍1.4 軟件過程 軟件過程模型是軟件開發全部過程、活動和任務的結構框架。它能直觀表達軟件開發全過程，明確規定要完成的主要活動、任務和開發策略。 軟件過程模型也常稱為： 軟件開發模型 軟件生存期模型 軟件工程范型軟件生存期模型可歸結為三大類 瀑布模型 原型模型 OO模型面向對象開發模型構件集成模型（component integration model）1. 瀑布模型 (線

37、形順序模型)可行性研究與計劃需求分析設計編碼運行維護測試定義階段開發階段維護階段1. 問題定義問題定義階段必須回答的關鍵問題是：“要解決的問題是什么?”如果不知道問題是什么就試圖解決這個問題，顯然是盲目的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。通過對客戶的訪問調查，系統分析員扼要地寫出關于問題性質、工程目標和工程規模的書面報告，經過討論和必要的修改之后這份報告應該得到客戶的確認。2. 可行性研究這個階段要回答的關鍵問題是：“對于上一個階段所確定的問題有行得通的解決辦法嗎?”系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計過程，也就是在較抽象

38、的高層次上進行的分析和設計過程。可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。可行性研究的結果是使用部門負責人作出是否繼續進行這項工程的決定的重要依據。可行性研究以后的那些階段將需要投入更多的人力物力。及時終止不值得投資的工程項目，可以避免更大的浪費。3. 需求分析這個階段的任務仍然不是具體解決問題，而是確定“為了解決這個問題，目標系統必須做什么？”，主要是確定目標系統必須具備哪些功能。系統分析員必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法表示。在需求分析階

39、段確定的系統邏輯模型是以后設計和實現系統的基礎。這個階段的一項重要任務，是用正式文檔準確地記錄對目標系統的需求，這份文檔通常稱為規格說明書(specification)。4. 總體設計這個階段必須回答的關鍵問題是：“概括地說，應該怎樣實現目標系統?”總體設計又稱為概要設計。首先，應該設計出實現目標系統的幾種可能的方案。通常至少應該設計出低成本、中等成本和高成本等3種方案。軟件工程師在充分權衡各種方案的利弊的基礎上，推薦一個最佳方案。制定出實現最佳方案的詳細計劃。一個程序應該由若干個規模適中的模塊按合理的層次結構組織而成。總體設計的另一項主要任務就是設計程序的體系結構，也就是確定程序由哪些模塊組

40、成以及模塊間的關系。5. 詳細設計詳細設計階段的任務就是把解法具體化，也就是回答這個關鍵問題：“應該怎樣具體地實現這個系統呢?”這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。詳細設計也稱為模塊設計，在這個階段將詳細地設計每個模塊，確定實現模塊功能所需要的算法和數據結構。6. 編碼和單元測試這個階段的關鍵任務是寫出正確的、容易理解、容易維護的程序模塊。程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言(必要時用匯編語言)，把詳細設計的結果翻譯成用選定的語言書寫的程序，并且仔細測試編寫出的每一個模塊。7. 綜合測試這個階段的關鍵任務是通過各種類型的測試(及相應的調試)使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定，由用戶對目標系統進行驗收。必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。8. 軟件維護維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。通常有4類維護活動：改正