第一篇：軟件危機是計算機軟件開發和維護過程中所遇到一系列嚴重問題

軟件危機是計算機軟件開發和維護過程中所遇到一系列嚴重問題

軟件工程是指導軟件開發和維護的一門學科

面向對象方法學的四個要點：面向對象方法=對象+類+繼承+用消息通信

面向對象三種模型：對象模型（描述系統數據結構），動態模型（描述系統控制

結構），功能模型（描述系統功能結構）

對象模型的五個層次：主題類，類與對象層，結構層，屬性層，服務層 瀑布模型：典型的文檔驅動模式。噴泉模型是對象模型

系統流程圖：是概括的描繪物理系統的傳統工具，他的思想是用圖形符號以黑

盒子形式描繪組成系統的每一個部件（程序，文檔，數據庫，人工

過程等）

簡易的應用規格說明書：是一種面向團隊的收集方法，他提倡用戶與開發者密

切合作，共同標識問題，提出解決問題要素，商討不同方案并指定

基本需求

實體聯系圖：描繪數據對象及之間的聯系，用來建立數據模型，簡稱E—R圖 實體聯系圖包含：實體（數據對象），關系和屬性三大基本成分

軟件工程使用的方法劃分成：半形式化，形式化，非形式化

總體設計：（1）系統設計階段（任務：確定系統具體實現方案）（2）結構設計

方案（任務：確定軟件結構）

維護的四項活動：改正性維護，完善性維護，適應性維護，預防性維護

簡答：

測試過程按4個步驟進行：單元測試（模塊測試），集成測試（子系統和系統測

試），確認測試（驗收測試），平行測試

決定軟件的可維護性因素：可理解性（），可測試性（），可修改性（），可移植

性（），可重用性（）

對象模型，功能模式和動態模型三者之間的關系：（1）針對每個類建立動態模

型，描述了類實例的生命周期或運行周期（2）狀態轉換驅使行為

發生（3）功能模型中的處理或用例對應于對象模型中的類所提供的服務（4）數據流圖中的數據存儲，源點和終點，通常是對象模

型中的對象（5）數據流圖中的數據流往往是對象模型中對象的屬

性值，也可能是整個對象（6）用例圖中的行為者，可能是對象模

型中的對象（7）功能模型中的處理可能產生動態模型中的事件（8）

對象模型描述數據流圖中的數據流，數據存儲，數據源地，終點的結構

第二篇：軟件工程是指導計算機軟件開發和維護的工程學科

軟件工程是指導計算機軟件開發和維護的工程學科。采用工程的概念、原理、技術和方法來

開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法

結合起來，這就是軟件工程。軟件工程強調使用生存周期方法學和各種結構分析及結構設計

技術。它們是在七十年代為了對付應用軟件日益增長的復雜程度、漫長的開發周期以及用戶

對軟件產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍采用的一個策略就是

“各個擊破”，也就是對問題進行分解然后再分別解決各個子問題的策略。軟件工程采用的生存周期方法學就是從時間角度對軟件開發和維護的復雜問題進行分解，把軟件生存的漫長

周期依次劃分為若干個階段，每個階段有相對獨立的任務，然后逐步完成每個階段的任務。

采用軟件工程方法論開發軟件的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地

進行開發。前一個階段任務的完成是開始進行后一個階段工作的前提和基礎，而后一階段任

務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階

段的開始和結束都有嚴格標準，對于任何兩個相鄰的階段而言，前一階段的結束標準就是后

一階段的開始標準。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從

技術和管理兩方面對這個階段的開發成果進行檢查，通過之后這個階段才算結束；如果檢查

通不過，則必須進行必要的返工，并且返工后還要再經過審查。審查的一條主要標準就是每個階段都應該交出“最新式的”（即和所開發的軟件完全一致的）高質量的文檔資料，從而

保證在軟件開發工程結束時有一個完整準確的軟件配置交付使用。文檔是通信的工具，它們

清楚準確地說明了到這個時候為止，關于該項工程已經知道了什么，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那么一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任

務時，應該采用適合該階段任務特點的系統化的技術方法，結構分析或結構設計技術。把軟

件生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便于不同人員分

工協作，從而降低了整個軟件開發工程的困難程度；在軟件生存周期的每個階段都采用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之后才開始下一階段的工作，這就使軟件開發工程的全過程以一種有條不紊的方式進行，保證了軟件的質量，特別是提高了軟件的可維護性。總之，采用軟件工程方法論

可以大大提高軟件開發的成功率，軟件開發的生產率也能明顯提高。目前劃分軟件生存周期

階段的方法有許多種，軟件規模、種類、開發方式、開發環境以及開發時使用的方法論都影

響軟件生存周期階段的劃分。在劃分軟件生存周期的階段時應該遵循的一條基本原則就是使

各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個

階段任務的復雜程度，簡化不同階段之間的聯系，有利于軟件開發工程的組織管理。一般說

來，軟件生存周期由軟件定義、軟件開發和軟件維護三個時期組成，每個時期又進一步劃分

成若干個階段。下面的論述主要針對應用軟件，對系統軟件也基本適用。軟件定義時期的任

務是確定軟件開發工程必須完成的總目標；確定工程的可行性，導出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，并且制定工程進度表。

這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟件定義時期通常進一步劃

分成三個階段，即問題定義、可行性研究和需求分析。開發時期具體設計和實現在前一個時

期定義的軟件，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。維護時期的主要任務是使軟件持久地滿足用戶的需要。具體地說，當軟件在使用過程

中發現錯誤時應該加以改正；當環境改變時應該修改軟件以適應新的環境；當用戶有新要求

時應該及時改進軟件滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次

維護活動本質上都是一次壓縮和簡化了的定義和開發過程。下面扼要介紹軟件生存周期每個

階段的基本任務和結束標準。問題定義問題定義階段必須回答的關鍵問題：“要解決的問題

是什么？”如果不知道問題是什么就試圖解決這個問題，顯然是盲目的，只會白白浪費時間

和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。通過問題定義階段的工作，系統分析員

應該提出關于問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負

責人的訪問調查，分析員扼要地寫出他對問題的理解，并在用戶和使用部門負責人的會議上

認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最后得出一份雙方

都滿意的文檔。問題定義階段是軟件生存周期中最簡短的階段，一般只需要一天甚至更少的時間。２可行性研究。這個階段要回答的關鍵問題：“對于上一個階段所確定的問題有行得

通的解決辦法嗎？”為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統

分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。可行性研究應該

比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值

得去解，是否有可行的解決辦法。在問題定義階段提出的對工程目標和規模的報告通常比較

含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），并且在此基

礎上更準確、更具體地確定工程規模和目標。然后分析員更準確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。可行性研究的結果是

使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取

得較大效益的那些工程項目才值得繼續進行下去。可行性研究以后的那些階段將需要投入要

多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。３需求分析這個階

段的任務仍然不是具體地解決問題，而是準確地確定“為了解決這個問題，目標系統必須做

什么”，主要是確定目標系統必須具備哪些功能。用戶了解他們所面對的問題，知道必須做

什么，但是通常不能完整準確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問

題；軟件開發人員知道怎樣使用軟件實現人們的要求，但是對特定用戶的具體要求并不完全

清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用

戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法描述表示系統的邏輯模型。

在需求分析階段確定的系統邏輯模型是以后設計和實現目標系統的基礎，因此必須準確完整

地體現用戶的要求。系統分析員通常都是計算機軟件專家，技術專家一般都喜歡很快著手進

行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續

提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結

束標準，需求分析階段必須提出完整準確的系統邏輯模型，經過用戶確認之后才能進入下一

個階段，這就可以有效地防止和克服急于著手進行具體設計的傾向。４總體設計。這個階段

必須回答的關鍵問題是：“概括地說，應該如何解決這個問題？”首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使

用計算機，那么是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是數

據庫。通常至少應該考慮下述幾類可能的方案：低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。中等成本的解決方案。這樣的系統不僅能夠很好地完成預

定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用

戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。高成本的“十全十美”的系統。這樣的系統具有用戶可能希望

有的所有功能和特點。系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估

計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上，推薦一個較好的系

統（最佳方案），并且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。上面的工作確定了解決問題的策略以及目標系統

需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟件的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。

通常用層次圖或結構圖描繪軟件的結構。５詳細設計。總體設計階段以比較抽象概括的方式

提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵

問題：“應該怎樣具體地實現這個系統呢？”這個階段的任務還不是編寫程序，而是設計出

程序的詳細規格說明。這種規格說明的作用很類似于其他工程領域中工程師經常使用的工程

藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。通常用ＨＩＰ

Ｏ圖（層次圖加輸入／處理／輸出圖）或ＰＤＬ語言（過程設計語言）描述詳細設計的結果。

６編碼和單元測試。這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。程

序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯

編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，并且仔細測試編寫出的每一

個模塊。７綜合測試。這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟件

達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結

構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或

在用戶積極參加下）對目標系統進行驗收。必要時還可以再通過現場測試或平行運行等方法

對目標系統進一步測試檢驗。為了使用戶能夠積極參加驗收測試，并且在系統投入生產性運

行以后能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。

通過對軟件測試結果的分析可以預測軟件的可靠性；反之，根據對軟件可靠性的要求也可以

決定測試和調試過程什么時候可以結束。應該用正式的文檔資料把測試計劃、詳細測試方案

以及實際測試結果保存下來，做為軟件配置的一個組成成分。８軟件維護。維護階段的關鍵

任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。通常有四類維護活動：改

正性維護，也就是診斷和改正在使用過程中發現的軟件錯誤；適應性維護，即修改軟件以適

應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟件使它更完善；預防性維護，即修改軟件為將來的維護活動預先做準備。雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出

維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟件設計，修改程序，測試

程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟件定義和開發的全過程的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析

維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟件設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟

件定義和開發的全過程。