軟體工程導論複習知識點

2022-03-14 04:08:21 字數 5377 閱讀 8174

1、軟體:

軟體定義:

軟體=程式+文件+資料

軟體特點:

1)、具有抽象性 2)、沒有明顯的製造過程 3)、軟體的維護比硬體的維護要複雜得多 4)、對計算機系統有著不同程度的依賴性 5)、尚未完全擺脫手工藝的開發方式 6)、軟體本身是複雜的 7)、軟體成本相當昂貴 8)、相當多的軟體工作涉及到社會因素

軟體的發展:

程式設計、程式系統、軟體工程

軟體危機:

軟體危機指的是軟體開發和維護過程中遇到的一系列嚴重問題。

軟體危機的問題:

如何開發軟體,怎樣滿足對軟體的日益增長的需求;如何維護數量不斷膨脹的已有軟體。

軟體危機表現:

1.開發成本難以控制,進度不可預計;

2.軟體系統的質量和可靠性很差,難以滿意;

3.軟體文件相當缺乏,軟體系統不可維護;

4.軟體開發生產率很低,軟體產品供不應求。

5.軟體產品成本十分昂貴。

軟體危機產生原因:

1)、軟體本身的特點 2)、對軟體開發與維護存在許多錯誤認識和做法 3)、軟體開發與維護的方法不正確

解決軟體危機途徑:

1)、將軟體開發看成是一種組織嚴密、管理嚴格、各類人員協同配合共同完成的工程專案。 2)、研究和推廣成功的軟體開發技術和方法。3)、開發和使用好的軟體工具。

軟體生命週期:

軟體所經歷的定義、開發、使用和維護直到廢棄所經歷的時期。

程式設計環境:

源程式編輯,編譯或解釋,鏈結,除錯和執行工具的集合

軟體工程環境:

軟體定義,設計和實現,測試和維護等各個階段所使用的軟體工具的集合

2、軟體工程:

軟體工程定義:

研究如何應用一些科學理論和工程上的技術來指導軟體的開發,用較少的投資獲得高質量的軟體的一門學科。

軟體工程性質:

涉及電腦科學、工程科學、管理科學、數學等領域,著重於如何建造乙個軟體系統。用工程科學中的觀點來進行費用估算、制定進度、制定計畫和方案。用管理科學中的方法和原理進行軟體生產的管理。

用數學的方法建立軟體開發中的各種模型和各種演算法,如可靠性模型,說明使用者需求的形式化模型等。

軟體工程三要素:

方法、工具和過程。

軟體方法:

是完成軟體開發的各項任務的技術方法,回答「如何做」的問題;工具是為方法的運用提供自動的或半自動的軟體支撐環境;過程是為了獲得高質量的軟體所需要完成的一系列任務的框架,它規定了完成各項任務的工作步驟。包括:傳統方法學物件導向方法學

需要解決的問題:

軟體成本、軟體可靠性、軟體維護、軟體生產率和軟體復用。

基本內容:

包括理論、結構、方法、工具、環境與規範等

目標:以較少的投資獲得易維護、易理解、可靠和高效率的軟體產品。

原則:即分解、抽象和資訊隱蔽、一致性和確定性

原理:工程化和系統化。

軟體過程:

軟體過程是把輸入轉化為輸出的一組彼此相關的資源和活動

從軟體開發的觀點看,它就是使用適當的資源(包括人員、硬軟體工具、時間等),為開發軟體進行的一組開發活動,在過程結束時將輸入(使用者要求)轉化為輸出(軟體產品)。

軟體工程過程包含四種基本的過程活動:

plan 軟體規格說明:規定軟體的功能及其執行的限制

do 軟體開發:產生滿足規格說明的軟體

check 軟體確認:確認軟體能夠完成客戶提出的要求

action 軟體演進:為滿足客戶的變更要求,軟體必須在使用的過程中演進

軟體工程的基本原理:

強調使用生存週期方法學、強調使用結構分析與結構設計任務

軟體工程的目標:

生產具有正確性、可用性以及開銷合宜的產品

1)、付出較低的開發成本 2)、達到要求的軟體功能 3)、取得較好的軟體效能 4)、開發的軟體易於移植 5)、需要較低的維護費用 6)、能按時完成開發 7)、及時交付使用

3、軟體生命週期:

生命週期基本流程:

問題定義→可行性研究→ 需求分析→ 總體設計(概要設計) → 詳細設計→ 編碼和單元測試→ 綜合測試→ 軟體維護。

瀑布模型:

這種方法是從乙個階段呈瀑布流入下乙個階段,所以這個模型就稱為「瀑布模型」。各項活動按自上而下,相互銜接的固定次序,如同瀑布逐級下落。每項活動均處於乙個質量環(輸入-處理-輸出-評審)中。

增量模型:

定義基本需求→將需求賦予增量構件 → 設計系統體系結構→ 開發增量構件→整合增量構件 →確認系統

把軟體產品分解成一系列的增量構件,在增量開發迭代中逐步加入。 每個構件由多個相互作用的模組構成,並且能夠完成特定的功能。增量開發方法的新演進版本叫做 「極限程式設計

演化模型:

先開發乙個「原型」軟體,完成部分主要功能,展示給使用者並徵求意見,然後逐步完善,最終獲得滿意的軟體產品。

快速原型方法是原型模型在軟體分析、設計階段的應用,用來解決使用者對軟體系統在需求分析上的模糊認識。是用來獲取使用者需求的,或是用來試探某種設計是否有效。一旦需求或設計確定下來,原型就將被拋棄

原型運用方式:

拋棄策略和附加策略

噴泉模型:

體現了迭代和無間隙的特性。

系統某個部分常常重複工作多次,相關物件在每次迭代中隨之加入演進的軟體成分。無間隙是指在各項開發活動,即分析、設計和編碼之間不存在明顯的邊界。噴泉模型是物件驅動的過程。

需求分析階段→設計階段→程式設計階段→整合與確認階段→維護階段→演高階段

微軟軟體開發過程:

戰略:靠改進特性與固定資源來激發創造力

①計畫階段 ②設計階段③開發階段④穩定化階段⑤發布階段。

微軟管理過程:

一、將大專案分成若干里程碑式的重要階段,各階段之間有緩衝時間,但不進行單獨的產品維護。

二、運用想象描述和對特性的概要說明指導專案。

三、根據使用者行為和有關使用者的資料確定產品特性及其優先順序。

四、建立模組化的和水平式的設計結構,並使專案結構反應產品結構的特點。

五、靠個人負責和固定專案資源實施控制。

4、可行性研究:

可行性研究實質:

可行性研究實質上是要進行一次簡化、壓縮了的需求分析和設計過程,要在較高層次上以抽象的方式進行需求分析和設計過程。

可行性研究目的:

可行性研究的目的就是用最小的代價在盡可能短的時間內確定該軟體專案是否能夠開發,是否值得開發,最後給決策者提供做與不做的依據。

可行性研究的任務:

1)、首先需要進行概要的分析研究,初步確定專案的規模和目標,確定專案的約束和限制。 2)、然後進行簡要的需求分析,抽象出該項目的邏輯結構,建立邏輯模型。 3)、最後從邏輯模型出發,經過壓縮的設計,探索出若干種可供選擇的主要解決辦法,對每種解決方法都要從多個方面研究它的可行性。

可行性研究內容:

(1)技術可行性 (2)經濟可行性 (3)操作可行性 (4)社會可行性(法律可行性) (5)抉擇

可行性研究的步驟:

可行性分析結論:

(1) 立即展開 (2) 推遲 (3) 修改後進行 (4) 不能進行 (5) 不必要進行

五、需求分析:

需求分析的過程:

需求分析的過程是開發人員與使用者共同協商,準確地定義未來系統的目標,確定為了滿足使用者的需求系統必須做什麼。並且使用軟體開發人員和使用者都能理解的語言準確地表達出來,即用 《需求規格說明書》 規範的形式準確地表達使用者的需求。

需求分析特點:

1)、問題的複雜性 2)、交流障礙(講究技巧和原則) 3)、不完備性和不一致性 4)、需求易變性(動態性)

軟體需求的任務:

1)、問題識別 2)、分析與綜合 3)、編寫文件 4)、技術審查和管理複審

需求文件:

1)、使用者需求報告 2)、需求規格說明書

需求分析原則:

需要能夠表達和理解問題的資訊域和功能域

需求分析的步驟:

1.需求獲取 2.需求提煉 3.需求描述 4.需求驗證

需求獲取的目的:

清楚的理解所要解決的問題完整獲取使用者需求

分析和描述系統的邏輯模型:

1. 建立起目標系統的邏輯模型 2. 沿資料流圖回溯

結構化分析方法:

面向資料流自頂向下逐步求精進行需求分析的方法。

高質量需求敘述的特性:

1)、正確 2)、可行性 3)、必要性 4)、優先權 5)、明確 6)、可證實 7)、完整 8)、可修改性 9)、可追蹤

6、系統總體設計:

軟體設計的任務:

把需求階段產生的軟體說明轉換為用適當手段表示的軟體設計文件

1)、軟體系統設計 2)、軟體結構設計 3)、資料結構及資料庫設計 4)、編寫概要設計文件 5)、評審

設計任務階段:

總體設計階段、詳細設計階段

軟體設計的全過程:

總體設計——總體設計複審——詳細設計——詳細設計複審

總體設計階段,應劃分出組成系統的物理元素:

程式、檔案、資料庫、人工過程和文件等,並確定系統中每個程式由哪些模組組成以及這些模組相互間的關係。

軟體設計的基本原理:

1)、抽象 2)、資訊隱蔽

模組獨立性:

指每個模組只完成系統要求的獨立的子功能,並且與其它模組的聯絡量最少且介面簡單。

兩個度量準則:

耦合性內聚性

模組間的耦合:

1)、非直接耦合 2)、資料耦合 3)、標記耦合 4)、控制耦合 5)、公共耦合 6)、內容耦合

如何降低模組間耦合度:

(1) 如模組必須存在耦合,選擇適當的耦合型別

原則:盡量使用資料耦合

少用控制耦合

限制公共耦合的範圍

堅決避免使用內容耦合

(2) 降低模組間介面的複雜性

面向資料流的設計方法:

1.變換流 2.事務流 3.設計過程

變換分析設計方法:

1 )、找出主加工、邏輯輸入和邏輯輸出 2)、 設計模組結構的頂層和第一層 3)、 設計中、下層模組

改進軟體結構設計的指導原則:

(1)程式結構盡可能與問題結構相對應 (2)模組功能的完整 (3)消除重複功能 (4)作用範圍應在控制範圍內 (5)減少高扇出爭取高扇入 (6)模組大小適中 (7)降低模組介面的複雜性 (8)模組功能可**

兩種典型的程式結構:

變換型程式、 事務型程式

兩種程式結構的共同特徵:

上層模組只負責控制、協調下層模組完成具體的操作

修改模組結構方法:

使判定同受其影響的操作盡可能靠近

詳細設計的基本任務:

1)、演算法設計 2)、資料結構設計 3)、資料庫物理設計 4)、其他設計:**設計、輸入/輸出設計、介面設計 5)、編寫詳細設計說明書 6)、評審

詳細設計內容:

詳細設計是根據每個模組的功能設計其邏輯描述、實現其法以及實現這些演算法的邏輯控制流程,並設計這些模組所需的區域性資料結構。

結構化程式設計:

1)、採用自頂向下,逐步求精的程式設計方法。 2)、使用三種基本控制結構構造程式:順序、選擇、迴圈。

軟體工程導論知識點

軟體是程式 資料及相關文件的完整集合。其中,程式是能夠完成預定功能和效能的可執行的指令序列 資料是使程式能夠適當地處理資訊的資料結構 文件是開發 使用和維護程式所需要的 資料。開發軟體時,對於提高軟體開發人員工作效率至關重要的是開發程式人員數量。軟體工程中描述軟體生存週期的瀑布型別一般包括計畫 需求...

軟體工程知識點

3 軟體工程原則 抽象 資訊隱蔽 模組化 區域性化 確定性 一致性 完備性和可驗證性。1 抽象 2 資訊隱蔽 3 模組化 4 區域性化 5 確定性 6 一致性 7 完備性 8 可驗證性 3.2 結構化分析方法 1 需求分析 需求分析方法有 1 結構化需求分析方法 2 物件導向的分析方法。2 結構化分...

軟體工程導論

1.軟體的定義 軟體是程式 資料及相關文件的完整集合。2.軟體危機的定義 表現 原因 定義 軟體危機是指在計算機軟體的開發和維護過程中所遇到的一系列嚴重問題。表現 a 對軟體開發成本和進度的估計常常很不準確。b 使用者對 已完成的 軟體系統不滿意的現象經常發生。c 軟體產品的質量往往靠不住。d 軟體...