第一章緒論
軟體:是計算機系統中與硬體相互依存的另一部分,它是包括程式,資料及其相關文件的完整集合。
軟體工程:是指導計算機軟體開發和維護的工程學科。它採用工程的概念、原理、技術和方法來開發與維護軟體,把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。
軟體危機:是指在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。主要是兩個問題:
1. 如何開發軟體,怎樣滿足對軟體的日益增長的需求。2.
如何維護數量不斷膨脹的已有軟體。主要表現:1.
對軟體開發成本和進度的估計不準確2. 使用者不滿意3. 軟體質量不高、可靠性差4.
軟體常常不可維護、錯誤難以改正5. 缺乏適當的文件資料6. 軟體成本佔系統總成本的比例逐年上公升7.
軟體開發速度跟不上計算機發展速度
產生軟體危機的原因
1. 與軟體本身的特點有關:軟體不同於硬體,它是計算機系統的邏輯部件而不是物理部件。
在寫出程式**並在計算機執行之前,軟體開發過程的進展情況較難衡量,軟體開發的質量也較難評價。因此,管理和控制軟體開發過程相當困難。
2. 軟體不易於維護:(1軟體維護通常意味著改正或修改原來的設計,客觀上使軟體較難維護。(2軟體不同於一般程式,它的規模大,不易於維護。
3. 在軟體開發過程中,或多或少地採用了錯誤的方法和技術。
4. 對使用者需求沒有完整準確的認識,就匆忙著手編寫程式。
解決軟體危機的途徑:⑴研製新一代體系結構的智慧型計算機,以改變軟體的實現方式,降低軟體的複雜性。目前尚未研製成功。
⑵採用工程化、規範化的開發方法來指導軟體的開發:這就是產生「軟體工程學」的背景,並在70年代形成了結構化分析、設計方法。⑶在求解方法上採用物件導向的軟體設計方法。
即在軟體開發中,以客觀世界的問題空間入手進行軟體設計,以減少求解方法空間與客觀世界問題空間存在的「鴻溝」。
「生命週期法」的起源:軟體工程採用的「生命週期法」,就是從時間角度對軟體開發和維護的複雜問題進行分解,把軟體生存的漫長週期依次劃分為若干個階段,每個階段有相對獨立的任務,然後再逐步完成每個階段的任務.
生命週期劃分的原則:任務的性質盡可能相同,從而降低每個階段任務的複雜性,簡化不同階段之間的聯絡,有利於軟體開發過程的組織管理。
生命週期的劃分:軟體生命週期一般分為:軟體定義(問題定義、可行性研究、需求分析、軟體開發(總體設計、詳細設計、編碼和測試、軟體使用與維護等三個時期八個階段。
問題定義:「要解決什麼問題?」可行性研究:
「上乙個階段所確定的問題是否有行得通的解決辦法」目的:用最小的代價在盡可能短的時間內確定問題是否能夠解決需求分析:「系統必須做什麼」對待開發軟體提出的需求進行分析並給出詳細的定義、編寫軟體需求規格說明書、提交管理機構評審概要設計:
把各項需求轉換成軟體的體系結構。結構中每一組成部分都是意義明確的模組,每個模組都和某些需求相對應詳細設計:對每個模組要完成的工作進行具體的描述,為源程式編寫打下基礎、編寫設計說明書,提交評審。
編碼:把軟體設計轉換成計算機可以接受的程式**,即寫成以某一種特定程式語言表示的「源程式清單」、寫出的程式應當是結構良好、清晰易讀的,且與設計相一致的軟體測試:單元測試:
查詢各模組在功能和結構上存在的問題並加以糾正組裝測試:將已測試過的模組按一定順序組裝起來,按規定的各項需求,逐項進行有效性測試,決定已開發的軟體是否合格,能否交付使用者使用軟體維護改正性維護:執行中發現了軟體中的錯誤需要修正適應性維護:
為了適應變化了的軟體工作環境,需做適當變更完善性維護:為了增強軟體的功能需做變更
軟體工程三要素:過程(為軟體工程的過程和方法提供自動化或半自動化的工具支援、方法(完成專案的技術手段(傳統方法學、物件導向方法學和工具(為軟體工程的過程和方法提供自動化或半自動化的工具支援
軟體工程釆用層次化的方法,每個層次都包括過程、方法、工具三要素.方法支撐過程和工具、過程和工具促進方法學的研究。將系統的、規範的、可量化的方法運用到軟體工程的始終,滲透到軟體工程的過程、方法和工具中。
傳統方法學(生命週期方法學原理: 採用結構化技術來完成軟體開發的各項任務,並使用適當的軟體工具或軟體工程環境來支援結構化技術的運用,即把軟體生命週期的全過程依次劃分為若干階段,然後順序地完成每個階段的任務。
軟體的生存週期及其開發模型:一、瀑布模型:優點:
通過設定里程碑,明確每階段的任務與目標。可為每階段制定開發計畫,進行成本預算,組織開發力量。通過階段評審,將開發過程納入正確軌道。
嚴格的計畫性保證軟體產品的按時交付。缺點:缺乏靈活性,不能適應使用者需求的改變。
開始階段的小錯誤被逐級放大,可能導致軟體產品報廢。返回上一級的開發需要十分高昂的代價。隨著軟體規模和複雜性的增加,軟體產品成功的機率大幅下降。
適應範圍:它主要適應於小規模和需求較為穩定的的軟體開發。瀑布模型一般適用於功能、效能明確、完整、無重大變化的軟體系統的開發。
例如作業系統、編譯系統、資料庫管理系統等系統軟體的開發。應用有一定的侷限性。二、快速原型模型:
基本思想:在獲取一組基本的需求定義後,利用高階軟體工具的可開發環境,快速地建立乙個目標系統的最初版本,並把它交給使用者試用、補充和修改,再進行新的版本開發。反覆進行這個過程,直到得出系統的「精確解」,即使用者滿意為止。
經過這樣乙個反覆補充和修改的過程,應用系統的「最初版本」就逐步演變為系統的「最終版本」。三、增量模型:一種非整體開發的模型。
根據增量的方式和形式的不同,分為基於瀑布模型的漸增模型和基於原型的快速原型模型。使用增量模型開發模型時,把軟體產品作為一系列的增量構件來設計、編碼、整合和測試。每個構件由多個相互作用的模組構成,並且能完成特定的功能。
第乙個增量構件往往提供最核心的功能。注意:在把每個新的增量構件整合到現有軟體體系結構中時,必須不破壞原來已經開發出的產品。
增量模型和瀑布模型之間的本質區別是:瀑布模型屬於整體開發模型,它規定在開始下乙個階段的工作之前,必須完成前一階段的所有細節。而增量模型屬於非整體開發模型,它推遲某些階段或所有階段中的細節,從而較早地產生工作軟體。
四、螺旋模型:在原型基礎上,進行多次原型反覆並增加風險評估,形成螺旋模型。模型、優點、缺點:
瀑布模型、文件驅動、系統可能不滿足客戶的需求;快速原型模型、關注滿足客戶需求、可能導致系統設計差、效率低,難於維護;增量模型、開發早期反饋及時,易於維護、需要開放式體系結構,可能會設計差、效率低;螺旋模型、風險驅動、風險分析人員需要有經驗且經過充分訓練
第二章可行性分析
可行性分析就是解決乙個專案是否有可行解以及是否值得去解的問題。該階段的主要任務就是用最小的代價在盡可能短的時間內確定問題是否能夠得到解決。主要任務:
具體地說,分析員應從下面三個方面對專案做出可行性分析:(1技術可行性:使用現有的技術能實現這個系統嗎?
(2經濟可行性:這個系統的經濟效益能超過它的開發成本嗎?(詳細在後面介紹成本/效益分析(3操作可行性:
系統的操作方式在該使用者組織內行得通嗎?必要時還應該進一步從法律、社會效益等更廣泛的角度研究每種解法的可行性。計算成本/效益分析
「可行性報告」中最主要的內容是:(1專案的背景:問題描述、實現環境和限制條件等(2管理概要與建議:
重要的研究結果(結論、說明、勸告和影響等(3推薦的方案(不止乙個:候選系統的配置與選擇最終方案的原則(4簡略的系統範圍描述:分配元素的可行性(5經濟可行性分析結果:
經費概算和預期的經濟效益等(6技術可行性(技術風險評價:技術實力分析、已有的工作及技術基礎和裝置條件等等(7法律可行性分析結果描述(8可用性評價:匯報使用者的工作制度和人員的素質,確定人機互動功能介面需求(9其他專案相關的問題:
如可能會發生的變更等等可行性研究報告由系統分析員撰寫,交由專案負責人審查,再上報給上級主管審閱。在可行性研究報告中,應當明確專案「可行還是不可行」,如果認為可行,接下來還要制定專案開發計畫書。
第三章軟體需求分析
需求分析:準確地定義未來系統的目標,確定為了滿足使用者的需求系統必須做什麼。用《需求規格說明書》 規範的形式準確地表達使用者的需求。
任務:確定對系統的綜合要求、分析系統的資料要求、匯出系統的邏輯模型、修正系統開發計畫。
確定對系統的綜合要求:1. 功能需求:
這方面的需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能2. 效能需求:
效能需求指定系統必須滿足的定時約束或容量約束,通常包括速度(響應時間、資訊量速率、主存容量、磁碟容量、安全性等方面的需求3. 可靠性和可用性需求:可靠性需求定量地指定系統的可靠性4.
出錯處理需求:這類需求說明系統對環境錯誤應該怎樣響應5. 介面需求:
介面需求描述應用系統與它的環境通訊的格式。常見的介面需求有:使用者介面需求;硬體介面需求;軟體介面需求;通訊介面需求6.
約束:設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件。常見的約束有:
精度;工具和語言約束;設計約束;應該使用的標準;應該使用的硬體平台7. 逆向需求:逆向需求說明軟體系統不應該做什麼8.
將來可能提出的要求:應該明確地列出那些雖然不屬於當前系統開發範疇,但是據分析將來很可能會提出來的要求。分析系統的資料要求:
分析系統的資料要求,這是軟體需求分析的乙個重要任務。分析系統的資料要求通常採用建立資料模型的方法(er圖—考點、資料字典、層次方框圖、wariner圖等工具匯出系統的邏輯模型:綜合上述兩項分析的結果可以匯出系統的詳細的邏輯模型,通常用資料流圖、實體-聯絡圖、狀態轉換圖、資料字典和主要的處理演算法描述這個邏輯模型。
修正系統開發計畫:根據在分析過程中獲得的對系統的更深入更具體的了解,可以比較準確地估計系統的成本和進度,修正以前制定的開發計畫。
需求獲取的常用方法:1.客戶訪談:
發放調查表和情景分析2. 面向資料流自頂向下求精:資料字典、資料流圖3.
簡易的應用規格說明:面向團隊需求收集法4.快速建立原型:
要點:建立使用者看的見得功能、快速、易修改
需求建模:所謂模型,就是為了理解事物而對事物做出的一種抽象,是對事物的一種無歧義的書面描述。通常,模型由一**形符號和組織這些符號的規則組成。
模型化或模型方法是通過抽象、概括和一般化,把研究的物件或問題轉化為本質(關係或結構相同的另一物件或問題,從而加以解決的方法。
需求分析的模型(結構化分析:資料模型er圖;功能模型資料流圖p41;行為模型狀態轉換圖
資料字典(dd,datadictionarydd是對所有與系統相關的資料元素的乙個有組織的列表,以及精確的、嚴格的定義,使得使用者和系統分析員對於輸入、輸出、儲存成分和中間計算有共同的理解。資料詞典是結構化分析方法中採用的表達資料元素的工具。它對資料流圖中所有自定義的資料元素、資料結構、資料檔案、資料流等進行嚴密而精確的定義。
加工說明:在資料流圖中,每乙個加工框中只是簡單地賦予了乙個加工名,這顯然不能表述加工的全部內容。乙個軟體系統的功能就是由這些加工的協同配合才得以實現的。
因此,需求分析中必須對每乙個加工進行說明。描述加工邏輯的工具:結構化語言:
介於自然語言和形式語言之間的語言特點:無確定語法、可分層、巢狀
判定表:描述多條件、多目標動作的形式化工具判定樹:由條件1、條件2得到結果
第四章軟體設計
軟體設計分為兩個階段:(1概要設計(總體設計確定軟體的結構以及各組成成分(子系統或模組之間的相互關係。分為:
系統設計階段,確定系統的具體實現方案;結構設計階段,確定軟體結構。設想供選擇的方案、選取合理的方案、推薦最佳方案、功能分解、設計軟體結構、設計資料庫、制定測試計畫、書寫文件、審查和複查(2詳細設計確定模組內部的演算法和資料結構,產生描述各模組程式過程的詳細文件。
軟體工程導論
1.軟體的定義 軟體是程式 資料及相關文件的完整集合。2.軟體危機的定義 表現 原因 定義 軟體危機是指在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。表現 a 對軟體開發成本和進度的估計常常很不準確。b 使用者對 已完成的 軟體系統不滿意的現象經常發生。c 軟體產品的質量往往靠不住。d 軟體...
軟體工程導論複習知識點
1 軟體 軟體定義 軟體 程式 文件 資料 軟體特點 1 具有抽象性 2 沒有明顯的製造過程 3 軟體的維護比硬體的維護要複雜得多 4 對計算機系統有著不同程度的依賴性 5 尚未完全擺脫手工藝的開發方式 6 軟體本身是複雜的 7 軟體成本相當昂貴 8 相當多的軟體工作涉及到社會因素 軟體的發展 程式...
軟體工程期末複習 2019
遼寧工業大學 軟體工程導論 第5版 期末複習資料 指導教師 鄂旭 複習時間 2011.11.10 2011.12.01 第一章1.軟體危機的含義？在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。2.軟體危機有那些典型表現？對軟體開發成本和進度的估計常常很不準確 使用者對 已完成的 軟體系統不滿...