第2章軟件工程_第1頁
第2章軟件工程_第2頁
第2章軟件工程_第3頁
第2章軟件工程_第4頁
第2章軟件工程_第5頁
已閱讀5頁,還剩70頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

第2章軟件工程2.1軟件工程的基本概念2.2軟件開發(fā)過程2.3系統(tǒng)定義2.4軟件實現(xiàn)2.5軟件維護2.6軟件開發(fā)管理2.1軟件工程的基本概念2.1.1軟件危機及其形成原因2.1.2軟件工程的定義2.1.3軟件工程的基本原則2.1.4軟件工程的基本內(nèi)容一、軟件的概念

軟件是計算機系統(tǒng)中與硬件相互依存的另一部分,它是包括程序、數(shù)據(jù)及其相關文檔的完整集合。 其中,程序是按事先設計的功能和性能要求編寫的指令序列;數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結構;文檔是與程序開發(fā)、維護和使用有關的圖文材料。 注:程序并不是軟件,程序只是軟件的組成部分。2.1.1軟件危機及其形成原因二、軟件的特點(1)軟件是一種邏輯實體。(2)軟件的開發(fā),是人的智力的高度發(fā)揮,而不是傳統(tǒng)意義上的硬件制造。(3)軟件維護與硬件的維修有著本質(zhì)的差別。(4)軟件的開發(fā)和運行常常受到計算機系統(tǒng)的限制,對計算機系統(tǒng)有著不同程度的依賴性。(5)軟件的開發(fā)至今尚未完全擺脫手工藝的開發(fā)方式,使軟件的開發(fā)效率受到很大限制。(6)軟件的開發(fā)是一個復雜的過程。(7)軟件的成本非常高昂。三、軟件危機及其形成原因什么是軟件危機軟件不符合用戶的實際需要軟件價格昂貴軟件開發(fā)項目超支和延期軟件質(zhì)量低,可靠性差軟件缺少適當?shù)奈臋n資料難于修改和維護軟件軟件危機的形成原因軟件本身是邏輯部件,質(zhì)量難以評價,潛在的錯誤在所難免軟件規(guī)模越來越大,軟件結構越來越復雜忽視需求分析的重要性,急于開始編程輕視軟件測試和輕視軟件維護軟件開發(fā)技術落后,生產(chǎn)方式落后,開發(fā)工具落后軟件危機的解決方法

必須消除存在的錯誤認識、樹立軟件工程觀念用工程化方法和途徑來開發(fā)和維護軟件

開發(fā)和使用更好的軟件工具

應該采取必要的管理措施

總之:技術措施+組織管理措施按工程化的原則和方法來組織和規(guī)范軟件開發(fā)過程,解決軟件研制中面臨的困難和混亂,從而根本上解決軟件危機。所謂軟件工程,就是研究大規(guī)模程序設計中的方法、工具和管理的一門工程科學。1968年北約組織在前聯(lián)邦德國格密斯舉行的國際學術會議上正式提出并使用了“軟件工程”的概念,運用工程學的基本原理和方法來組織和管理軟件生產(chǎn)。后來還發(fā)展了相關的心理學、生理學和經(jīng)濟學等方面的學科。軟件工程誕生了,它是解決軟件危機唯一有效的方法。定義一:軟件工程是科學知識在設計和構造計算機程序以及開發(fā)、運作和維護這些程序所要求的有關文檔編制中的實際應用。定義二:為了經(jīng)濟地獲得可靠的能在實際的計算機上運行的軟件所確立和使用的健全的工程原理。定義三:對軟件開發(fā)、運行、維護、退役的系統(tǒng)研究方法。

定義四:對軟件開發(fā)、運行、維護的系統(tǒng)化的、有紀律的、可定量的方法的應用,即對軟件的工程化的應用。定義五:軟件工程是指導計算機軟件開發(fā)和維護的一門學科,它采用工程的概念、原理、技術和方法,把經(jīng)過時間考驗而證明是正確的管理技術和與技術方法結合起來用于開發(fā)軟件。2.1.2軟件工程的定義用分階段的生命周期計劃嚴格管理

堅持進行階段評審

實行嚴格的產(chǎn)品控制采用現(xiàn)代程序設計技術

工作成果應當能夠清楚地評審開發(fā)小組的成員應少而精

承認不斷改進軟件工程實踐的必要性2.1.3七條基本原則軟件生存周期模型指導整個軟件開發(fā)過程軟件分析系統(tǒng)分析、可行性分析、軟件開發(fā)計劃、需求分析軟件設計總體設計、詳細設計

軟件實現(xiàn)編程序軟件測試

軟件維護

軟件管理

成本估算、風險分析、進度安排、人員組織、軟件質(zhì)量保證2.1.4軟件工程的基本內(nèi)容2.2軟件開發(fā)過程2.2.1軟件開發(fā)的主要階段2.2.2軟件生命周期模型2.2.3模塊化軟件開發(fā)原則2.2.4軟件開發(fā)方法軟件從產(chǎn)生、發(fā)展到淘汰要經(jīng)歷定義、開發(fā)和維護三大階段定義階段細分成可行性論證、需求分析開發(fā)階段細分成總體設計、詳細設計、實現(xiàn)、集成測試和確認測試維護階段細分成軟件使用、修改維護、退役2.2.1軟件開發(fā)的主要階段軟件產(chǎn)品從形成概念開始,經(jīng)過開發(fā)、使用和維護,直到退役的全過程九個階段:2.2.2軟件生命周期模型軟件生命周期瀑布模型將軟件生存周期的各項活動規(guī)定為依照固定順序連接的若干階段工作,形如瀑布流水,最終得到軟件產(chǎn)品。瀑布模型的特點線性開發(fā)序列:每一階段任務必須通過評審才能進入下一階段,直線前進避免大的返工,允許局部的返工瀑布模型的局限性明確全部需求困難甚至不現(xiàn)實開發(fā)周期過長、用戶不能及時提出修改意見軟件生存周期漸增模型又稱演化模型又稱原型模型用主動的正常的迭代避免被迫的不正常的反復程序員與用戶反復交互原型模型的特點采用軟件重用技術和強有力的快速開發(fā)工具采用主動的、正常的迭代避免了瀑布模型被迫的、不正常的返工有助于用戶和軟件開發(fā)人員對需求的定義和確認原型模型的局限性不收斂于開發(fā)者預定目標資源規(guī)劃和管理較為困難更新文檔麻煩抽象自頂向下逐步求精模塊化信息隱蔽與局部化模塊獨立啟發(fā)式規(guī)則2.2.3模塊化軟件開發(fā)原則把大型軟件按照規(guī)定的原則劃分為一個個較小的、相對獨立但又相關的模塊的設計方法,叫做模塊化設計(modulardesign)。模塊(module)是數(shù)據(jù)說明和可執(zhí)行語句等程序對象的集合,每個模塊單獨命名并且可以通過名字對模塊進行訪問實現(xiàn)模塊化設計的重要指導思想是分解、信息隱藏和模塊獨立性。分解 設函數(shù)C(x)定義問題x的復雜程度,函數(shù)E(x)確定解決問題x所需要的工作量(時間)。對于兩個問題Pl和P2,如果C(P1)>C(P2),

顯然 E(P1)>E(P2)

根據(jù)人類解決一般問題的經(jīng)驗,如果一個問題由Pl和P2兩個問題組合而成,那么它的復雜程序大于分別考慮每個問題時的復雜程度之和,即

C(Pl+P2)>C(P1)+C(P2)

綜上所述,可得到下面的不等式

E(Pl+P2)>E(Pl)+E(P2)模塊化模塊完成特定的子功能可以組合、分解、更換的單元,如過程、函數(shù)、子程序、宏等模塊化解決一個復雜問題時,自頂向下逐層將軟件分解成若干模塊的過程目的:降低軟件的復雜性模塊化軟件開發(fā)原則模塊劃分的指導原則模塊可分解性:能把問題分解為子問題的系統(tǒng)化機制模塊可組裝性:能把現(xiàn)有的模塊組裝成新系統(tǒng)模塊可理解性:一個模塊作為獨立單元無需參考其它模塊來理解模塊連續(xù)性:系統(tǒng)需求的微小修改只導致對個別模塊,而不是對整個系統(tǒng)的修改模塊保護性:一個模塊內(nèi)出現(xiàn)異常情況時,它的影響局限在該模塊內(nèi)部模塊化軟件開發(fā)原則模塊與成本的關系模塊化軟件開發(fā)原則信息隱蔽與局部化信息隱蔽:一個模塊內(nèi)包含的信息(過程或數(shù)據(jù))對于不需要這些信息的其它模塊來說不可見(不能訪問)局部化:將關系密切的軟件元素的位置盡量靠近信息隱蔽與局部化有利于軟件的可維護性,可以防止誤操作和誤修改模塊化軟件開發(fā)原則模塊獨立模塊獨立性:模塊化、抽象、信息隱蔽和局部化直接結果模塊獨立的好處:使軟件開發(fā)更容易、適合分工合作使軟件測試和維護更容易模塊獨立的度量內(nèi)聚:一個模塊內(nèi)部各元素之間彼此結合的緊密程度的度量耦合:不同模塊之間互連程度的度量模塊化軟件開發(fā)原則啟發(fā)式規(guī)則改進軟件結構提高模塊獨立性模塊規(guī)模應該適中模塊之間的調(diào)用關系應當按照層次化組織模塊的深度、寬度、扇出和扇入都應適當設計單入口單出口的模塊模塊功能應該可以預測模塊化軟件開發(fā)原則對軟件分析方法、軟件設計方法軟件實現(xiàn)(編碼)方法的總稱。結構化方法(StructuredMethod)面向對象方法(Object-OrientedMethod)2.2.4軟件開發(fā)方法2.3系統(tǒng)定義2.3.1可行性分析2.3.2需求分析可行性分析目的用最小的代價在盡可能短的時間內(nèi)確定問題是否能夠解決任務在澄清了問題定義之后,分析員首先應該導出系統(tǒng)的邏輯模型,然后從系統(tǒng)邏輯模型出發(fā),探索出若干種可供選擇的主要解法(即系統(tǒng)實現(xiàn)方案)。最后仔細研究每種解法的可行性。2.3.1可行性分析一般說來,可行性研究應該從下述幾方面進行:(1)技術可行性:指使用現(xiàn)有的技術能否完成這個項目。(2)經(jīng)濟可行性:指通過對軟件開發(fā)項目進行成本/效益估計,以確定軟件系統(tǒng)可能帶來的經(jīng)濟效益能否超過研制和維護此系統(tǒng)所需的費用。(3)社會因素的考慮:軟件開發(fā)是否會侵犯他人、集體或國家的利益,是否違反國家的法律并可能由此而承擔法律責任。步驟確定項目規(guī)模和目標研究正在運行的系統(tǒng)建立新系統(tǒng)的高層邏輯模型導出和評價各種方案推薦可行方案編寫可行性分析報告軟件開發(fā)計劃通過可行性分析,如果開發(fā)軟件系統(tǒng)可行的話,接著要制定軟件的開發(fā)計劃。內(nèi)容資源計劃:人力資源、硬件資源、軟件資源成本預算:估計總的開發(fā)成本進度安排:確定最終的軟件交付日期、在交付日期內(nèi)安排和分配工作量需求分析需求分析目標解決“做什么(Whattodo)”,而不是“怎么做(Howtodo)”既是軟件開發(fā)依據(jù),也是軟件驗收標準與用戶充分溝通,去偽存真,去粗存精通信瓶頸:用戶vs

開發(fā)人員階段性標志:軟件需求規(guī)格說明(SRS:SoftwareRequirementsSpecification)

2.3.2需求分析一、需求分析任務確定軟件系統(tǒng)的綜合要求功能要求性能要求系統(tǒng)數(shù)據(jù)接口要求安全性保密性和可靠性要求系統(tǒng)運行要求異常處理要求等分析軟件系統(tǒng)的數(shù)據(jù)要求建立系統(tǒng)的邏輯模型評估項目開發(fā)計劃(成本、進度)二、需求分析工具層次方框圖Warnier圖IPO圖(輸入/處理/輸出)三、需求分析方法結構化分析方法結構化分析方法(StructuredAnalysis,簡稱SA方法)是70年代中期提出的一種面向數(shù)據(jù)流、自頂向下、逐步求精進行需求分析的方法。結構化分析方法中使用的工具主要包括:數(shù)據(jù)流圖、數(shù)據(jù)字典、結構化語言、判定表和判定樹。 其中數(shù)據(jù)流圖用以表達系統(tǒng)內(nèi)數(shù)據(jù)的運動情況;數(shù)據(jù)字典用以定義系統(tǒng)中的數(shù)據(jù);結構化語言、判定表和判定樹都是用以描述數(shù)據(jù)流的加工的工具。面向對象分析方法2.4軟件實現(xiàn)2.4.1總體設計2.4.2詳細設計2.4.3編碼2.4.4測試一、總體設計內(nèi)容總體設計又稱概要設計解決“如何做(Howtodo)”設計供選擇的方案推薦最佳方案設計軟件結構,劃分功能模塊,定義各功能模塊的接口設計數(shù)據(jù)結構和數(shù)據(jù)庫用戶界面設計制定測試計劃編寫總體設計階段的文檔評審總體設計方案2.4.1總體設計軟件實現(xiàn)二、總體設計的圖形工具層次圖HIPO圖(層次圖加輸入/處理/輸出圖)結構圖軟件實現(xiàn)三、總體設計的設計方法結構化設計自頂向下基于數(shù)據(jù)流的設計方法面向對象設計軟件實現(xiàn)

詳細設計以總體設計階段的工作為基礎的,但又不同于總體設計,主要表現(xiàn)為以下兩個方面:(1)在總體設計階段,數(shù)據(jù)項和數(shù)據(jù)結構以比較抽象的方式描述,而詳細設計階段則應在此基礎上給出足夠詳細描述。(2)詳細設計要提供關于算法的更多的細節(jié),例如:總體設計可以聲明一個模塊的作用是對一個表進行排序,詳細設計則要確定使用哪種排序算法。在詳細設計階段為每個模塊增加了足夠的細節(jié)后,程序員才能夠以相當直接的方式進行下一階段的編碼工作。2.4.2詳細設計軟件實現(xiàn) 詳細設計的任務和原則一、詳細設計的任務1)確定每個模塊的算法。

2)確定每一個模塊的數(shù)據(jù)組織。

3)為每個模塊設計一組測試用例。

4)編寫詳細設計說明書。軟件實現(xiàn)

二、詳細設計的原則(1)模塊的邏輯描述正確可靠、清晰易讀。(2)采用結構化程序設計方法,改善控制結構,降低程序復雜度,提高程序的可讀性、可測試性和可維護性。

軟件實現(xiàn)三、詳細設計的工具過程設計語言(PDL:ProcedureDesignLanguage)又稱偽碼,半形式化、易編輯、易自動生成程序流程圖易上手、非結構化盒圖(N-S圖)結構化、功能域明確PAD圖結構化、可用于數(shù)據(jù)結構、易自動生成軟件實現(xiàn)四、詳細設計的方法面向數(shù)據(jù)結構的設計方法:以數(shù)據(jù)結構為中心結構化設計方法以數(shù)據(jù)流為中心面向對象設計方法以對象為中心軟件實現(xiàn)2.4.3編碼編碼(實現(xiàn)):俗稱編程序(Programming)編碼任務選擇一種程序設計語言將詳細設計文檔“翻譯”為程序(源程序代碼)單元測試(調(diào)試)編碼原則高效+技巧安全+可靠時間、空間效率可用性、可維護性、可移植性良好的編程風格可以減少軟件錯誤階段性標志:源程序代碼編碼風格

編碼風格實際上是一種編碼原則。從20世紀70年代以來,編碼的目標從強調(diào)效率轉變到強調(diào)清晰。與此相應,編碼風格也從追求“聰明”和“技巧”,變?yōu)樘岢昂喢鳌焙汀爸苯印薄H藗冎饾u認識到,良好的編碼風格能在一定程度上彌補程序設計語言存在的缺點。反之,如果不注意編碼風格,即使使用了結構化的現(xiàn)代語言,也很難寫出高質(zhì)量的程序。一、代碼文檔化:指編碼時適當選擇標識符的名字、適當安排注釋和注重程序的整個組織形式。二、數(shù)據(jù)說明:程序或模塊在其可執(zhí)行部分的前面都集中了一些說明語句,出于閱讀理解和維護的要求,最好使其規(guī)范化,使說明的先后次序固定。三、語句構造:每條語句都應當簡單而直接,同時也不應為了追求運行效率而使代碼復雜化,這樣會減低程序的可讀性。四、輸入/輸出:源程序的輸入輸出風格必須滿足運行工程學的需要。程序效率 盡管效率是值得追求的目標,但不應為了非必需的效率提高而犧牲代碼的清晰性、可讀性和正確性。應記住下面三條準則。(1)效率是一種性能需求,目標值應當在需求分析階段給出。軟件效率應以需求為準,不應以人力所及為準。(2)好的設計可以提高效率。(3)代碼效率與代碼的簡單性相關。一、代碼效率

(1)應先簡化算術和邏輯的表達式。

(2)仔細研究嵌套的循環(huán),以確定是否有語句可以從內(nèi)層往外移。

(3)盡量避免使用多維數(shù)組。

(4)盡量避免使用指針。

(5)使用執(zhí)行時間短的算術運算。

(6)即使語言允許,一般也不要采用混合數(shù)據(jù)類型。

(7)盡量使用整數(shù)表達式和布爾表達式。二、輸入/輸出的效率(1)所有輸入/輸出都應該有緩沖,以減少過多的通信次數(shù)。

(2)對輔存(如磁盤),應選用最簡單的訪問方法。

(3)輔存的輸入/輸出,應該以塊為單位進行。

(4)終端和打印機的輸入/輸出,應當考慮設備的特性,以提高輸入/輸出的質(zhì)量和速度。

(5)不應當采用不能被人們所理解的超高效的輸入/輸出。結構化程序設計采用自頂向下、逐步求精的設計方法;采用單入口單出口的控制結構;只包含順序、選擇和循環(huán)三種控制結構;軟件實現(xiàn)一、軟件測試的目標測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程;好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案;成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。二、測試原則測試不能證明軟件沒有錯誤應避免程序員測試自己的程序對合法的和非法的輸入都要測試測試用例(包括輸入及預期輸出)必須高效2.4.4軟件測試軟件實現(xiàn)測試原則盡早地和不斷地進行軟件測試程序員應避免檢查自己的程序要預先確定測試用例設計的測試用例應當包括合理的輸入條件和不合理的輸入條件充分注意測試中的群集現(xiàn)象嚴格執(zhí)行測試計劃,排除測試的隨意性應當對每個測試結果做全面檢查妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告軟件實現(xiàn)三、測試分類單元測試(又稱模塊測試)時期:編碼階段定義:對軟件設計的最小單位(程序模塊)進行的測試方法:采用白盒測試法輔之以黑盒測試法內(nèi)容:模塊接口測試、局部數(shù)據(jù)結構測試、路徑測試、錯誤處理測試、邊界測試組裝測試(又稱集成測試)時期:編碼完成階段定義:在單元測試的基礎上將所有模塊按照設計要求組裝為完整的系統(tǒng)方法:漸增式測試和非漸增式測試內(nèi)容:各模塊的接口軟件實現(xiàn)確認測試定義:驗證軟件的功能、性能及其他特性是否與用戶的要求一致方法:測試、β測試內(nèi)容:有效性測試和驗收測試階段:即將交付使用系統(tǒng)測試定義:把通過確認測試的軟件作為整個計算機系統(tǒng)的一個元素與其他元素結合在一起在實際運行(使用)環(huán)境下,對計算機系統(tǒng)進行一系列的組裝測試和確認測試軟件實現(xiàn)四、白盒測試前提:完全了解程序的結構和處理過程方法:窮盡測試、邏輯覆蓋

邏輯覆蓋的不同標準語句覆蓋選擇足夠多的測試數(shù)據(jù),使被測程序中每個語句至少執(zhí)行一次判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋軟件實現(xiàn)五、黑盒測試定義:只檢查程序功能是否能按照需求規(guī)格說明書的規(guī)定正常運行,程序是否能接收輸入數(shù)據(jù)并產(chǎn)生正確的輸出信息,并且保持外部信息的完整性。方法:等價類劃分僅選取少量最有代表性的輸入數(shù)據(jù)邊界值分析使程序運行在邊界情況(下標,循環(huán)次數(shù))下錯誤推測軟件實現(xiàn)六、軟件調(diào)試

任務:測試之后進一步診斷和改正程序中的錯誤步驟:確定錯誤的位置確定問題的原因方法:輸出存儲器內(nèi)容適當插入打印語句使用專門的調(diào)試工具調(diào)試策略

試探法、回溯法、歸納法、演繹法軟件實現(xiàn)2.5軟件維護2.5.1什么是軟件維護2.5.2軟件維護分類2.5.3軟件維護的過程軟件維護是軟件生命周期的最后一個階段,它是指已完成開發(fā)工作,交付使用后,對軟件產(chǎn)品所進行的一些軟件工程活動。軟件維護的必要性運行中發(fā)現(xiàn)錯誤適應軟硬件環(huán)境變化適應功能需求變化維護成本通常高大開發(fā)成本的4倍2.5.1什么是軟件維護軟件維護決定可維護性的因素可理解性:理解軟件的難易程度可測試性:測試和診斷軟件中錯誤的難易程度可修改性:修改軟件的難易程度各類文檔軟件維護的分類改正性維護:在軟件運行中發(fā)生異?;蚬收蠒r進行。適應性維護:為使該軟件能適應外部環(huán)境的變動。完善性維護:為擴充軟件的功能,提高原有軟件性能而開展的軟件工程活動。軟件維護在軟件維護時,必然會對源程序進行修改,為了正確、有效地修改源程序,需要經(jīng)歷下列步驟:分析和理解程序修改程序重新驗證程序軟件維護的組織維護文檔的編寫軟件維護2.5.3軟件維護的過程2.6軟件開發(fā)管理2.6.1質(zhì)量管理2.6.2進度安排2.6.3人員管理2.6.4風險分析2.6.5成本/效益分析軟件質(zhì)量:定量比較困難ISO軟件質(zhì)量模型的質(zhì)量特性和質(zhì)量子特性組成:功能性適應性、準確性、互用性、依從性、安全性可靠性成熟、容錯、易恢復易使用性易理解、易學、易操作效率時間特性、資源特性可維護性易分析、易修改、穩(wěn)定、易測試可移植性適應性、易安裝、一致性、易替換軟件開發(fā)管理2.6.1質(zhì)量管理

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論