一、瀑布模型

? 嚴格區(qū)分階段，每個階段因果關系緊密相連，只適合需求明確的項目

缺點：軟件需求完整性、正確性難確定；嚴格串行化，很長時間才能看到結果；瀑布模型要求每個階段一次性完全解決該階段工作，不現(xiàn)實。

二、原型模型?

適合需求不明確的項目

原型模型兩個階段：1、原型開發(fā)階段 2、目標軟件開發(fā)階段

拋棄型原型與演化型原型

三、原型及相關模型

四、V模型

五、迭代與增量

增量型：一塊一塊有增加

迭代型：一輪一輪在變好

?六、螺旋模型

七、構件組裝模型

優(yōu)點：易擴展、易重用、降低成本、安排任務更靈活。

確定：構件設計要求經(jīng)驗豐富的架構師、設計不好的構件難重用、強調重用可能犧牲其他指標（如性能）、第三方構件質量難控制。

八、基于構件的軟件工程（CBSE）

CBSE體現(xiàn)了購買而不是重新構造的哲學

CBSE的特征：

• 可組裝性：所有外部交互必須通過公開定義的接口進行
• 可部署性：構件總是二進制式的，能作為一個獨立實體在平臺上運行
• 文檔化：用戶根據(jù)文檔來判斷構件是否滿足需求
• 獨立性：可以在無其他特殊構件的情況下進行組裝和部署
• 標準化：符合某種標準化的構件模型

構件的組裝：

• 順序組裝：按順序調用已經(jīng)存在的構件，可以用兩個已經(jīng)存在的構件來創(chuàng)造一個新的構件
• 層次組裝：被調用構件的“提供”接口必須和調用構件的“請求”接口兼容
• 疊加組裝：多個構件合并形成新構件，新構件整合原構件的功能，對外提供新接口

?九、快速應用開發(fā)模型（RAD）

主流程采用瀑布模型，在流程引入大量的構件

十、統(tǒng)一過程（UP，RUP）

十一、敏捷方法概述

11.1、敏捷方法-XP

強調四大價值觀：溝通（加強面對面溝通），簡單（不過度設計），反饋（及時反饋），勇氣（接受變更的勇氣）

實踐規(guī)則：結對編程（兩個人寫代碼，一個人寫，一個人審核）、持續(xù)集成

?11.2、敏捷方法-SCRUM

核心思想：每次選一部分進行迭代，一個迭代一到四周，側重項目管理

11.3 其他敏捷方法

水晶方法：提倡“機動性”的方法，擁有對不同類型項目非常有效的敏捷過程

特征驅動開發(fā)方法（FDD）：認為有效的軟件開發(fā)需要三要素：人、過程和技術。定義了六種關鍵的項目角色：項目經(jīng)理、首席架構設計師、開發(fā)經(jīng)理、主程序員、程序員和領域專家。

開放式源碼：程序開發(fā)人員在地域上分布很廣，其他方法強調集中辦公

ASD方法：其核心是三個非線性的、重疊的開發(fā)階段：猜測、合作與學習

動態(tài)系統(tǒng)開發(fā)方法（DSDM）：倡導以業(yè)務為核心

十二、逆向工程

實現(xiàn)級：包括程序的抽象語法樹、符合表、過程的設計表示

結構級：包括反映程序分量之間互相依賴關系的信息，例如調用圖、結構圖、程序和數(shù)據(jù)結構

功能級：包括反映程序段功能及程序段之間關系的信息，例如數(shù)據(jù)和控制流模型

領域級：包括反映程序分量或程序實體與應用領域概念之間對應關系的信息，如實體關系模型

相關概念

（1）重構/重組。重構是指在同一個抽象級別上轉換系統(tǒng)的描述形式。

（2）設計恢復：指借助工具從已有程序中抽象出有關數(shù)據(jù)設計、總體結構設計和過程設計等方面的信息

（3）逆向工程：逆向工程是分析程序。力圖在比源代碼更高抽象層次上建立程序的表示過程，逆向工程是設計的恢復過程

（4）正向工程：指不僅從現(xiàn)有系統(tǒng)中恢復設計信息，而且使用該信息去改變或重構現(xiàn)有系統(tǒng)，以改善其整體質量

（5）再工程/重構工程：再工程是對現(xiàn)有系統(tǒng)的重新開發(fā)過程，包括逆向工程、新需求的考慮過程和正向工程三個步驟

?十三、凈室軟件工程

凈室即無塵室、潔凈室。就是一個受控污染級別的環(huán)境。

使用盒結構規(guī)約（或形式化方法）進行分析和設計建模，并且強調將正確性驗證，而不是測試，作為發(fā)現(xiàn)和消除錯誤的主要機制。

使用統(tǒng)計的測試來獲取認證被交付的軟件的可靠性所必需的出錯率信息。

技術手段

• 統(tǒng)計過程控制下的增量式開發(fā)：控制迭代
• 基于函數(shù)的規(guī)范和設計：盒子結構 定義3種抽象層次：行為視圖（黑盒）->有限狀態(tài)機視圖（狀態(tài)盒）->過程視圖（明盒）
• 正確性驗證：凈室工程的核心
• 統(tǒng)計測試和軟件認證：使用統(tǒng)計學原理，總體太大時必須采用抽樣方法

缺點：

• 太理論化，正確性驗證的步驟比較困難且耗時
• 開發(fā)小組不進行傳統(tǒng)的模塊測試，不現(xiàn)實
• 脫胎于傳統(tǒng)軟件工程，不可避免帶有傳統(tǒng)軟件工程的一些弊端

十四、需求工程-概述

軟件需求是指用戶對系統(tǒng)在功能、行為、性能、設計約束等方面的期望

十五、需求工程-需求獲取

需求獲取方法

• 用戶面談：交互好。成本高，要有領域知識支撐
• 聯(lián)合需求計劃：高度組織的群體會議，各方參與，了解想法，消除分歧。交互好，成本高
• 問卷調查：用戶多，無法一一訪談，成本低
• 現(xiàn)場觀察：針對復雜業(yè)務流程和操作
• 原型化方法：通過簡易系統(tǒng)方式解決早期需求不確定的問題
• 頭腦風暴法：一群人圍繞新業(yè)務，發(fā)散思維，不產生新的觀點

十六、需求分析?

需求分析分兩條線——結構化需求分析和面向對象需求分析

結構化分析做三個模型——功能模型（數(shù)據(jù)流圖DFD）、數(shù)據(jù)模型和行為模型

十七、OOA

UML（統(tǒng)一建模語言）：與平臺無關，語言無關，由構造塊、規(guī)則和公共機制組成。

公共機制：

• 規(guī)格說明：事物語義的細節(jié)描述，它是模型真正的核心
• 修飾：通過修飾來表達更多的信息
• 公共分類：類與對象、接口與實現(xiàn)
• 擴展機制：允許添加新的規(guī)則

規(guī)則：

• 范圍：給一個名字以特定含義的語境
• 可見性：咋樣使用或看見名字
• 完整性：事物如何正確、一致地相互聯(lián)系
• 執(zhí)行：運行或模擬冬天模型的含義是什么

構造塊：

• 事物
  • 結構事物：最靜態(tài)的部分，包括：類、接口、協(xié)作、用例、活動類、構件和節(jié)點
  • 行為事物：代表時間和空間上的動作。包括：消息、動作次序、連接
  • 分組事物：看成是個盒子。如：包、構件
  • 注釋事物：UML模型的解釋部分。描述、說明和標注模型的元素
• 關系
• 圖

十八、UML-4+1視圖

邏輯視圖展現(xiàn)系統(tǒng)的功能,實現(xiàn)視圖展現(xiàn)源代碼結構

十九、需求定義

嚴格定義法

• 所有需求都能夠被預先定義
• 開發(fā)人員與用戶之間能夠準確而清晰地交談
• 采用圖形/文字可以充分體現(xiàn)最終系統(tǒng)

原型法

• 并非所有的需求都能在開發(fā)前被準確的說明
• 項目參加者之間通常都存在交流上的困難
• 有適合的系統(tǒng)開發(fā)環(huán)境
• 反復是完全需要和值得提倡的，需求一旦確定，就應遵從嚴格的方法

二十、需求驗證

二十一、需求跟蹤

?二十二、需求變更管理過程

變更審批由CCB負責

二十三、軟件系統(tǒng)建模

二十四、人機界面設計

黃金三法則

• 置于用戶控制之下
• 減少用戶的記憶負擔
• 保持界面的一致性

二十五、結構化設計

結構化設計包括：

• 概要設計（外部設計）：功能需求分配給軟件模塊，確定每個模塊的功能和調用關系，形成模塊結構圖
• 詳細設計（內部設計）：為每個具體任務選擇適當?shù)募夹g手段和處理方法

結構化設計原則：

• 模塊獨立性原則（高內聚、低耦合）
• 保持模塊的大小適中
• 多扇入（復用率高），少扇出（耦合度低）
• 深度（一層一層的調用關系）和寬度均不宜過高

內聚

耦合

模塊四要素

• 輸入和輸出：模塊的輸入來源和輸出去向都是同一個調用者，即一個模塊從調用者那兒取得輸入，進行加工后再把輸出返回調用者。
• 處理功能：指模塊把輸入轉換成輸出所做的工作
• 內部數(shù)據(jù)：指僅供該模塊本身引用的數(shù)據(jù)
• 程序代碼：指用來實現(xiàn)模塊功能的程序

?二十六、面向對象設計

基本過程

類的分類

• 邊界類：機器接口（API接口）、人機交互（用戶界面：顯示屏，二維碼等）
• 控制類：解決應用邏輯、業(yè)務邏輯和數(shù)據(jù)訪問邏輯
• 實體類：對接數(shù)據(jù)表

設計原則

• 單一職責原則：設計目的單一的類
• 開放-封閉原則：對外開放，對修改封閉
• 李氏替代原則：子類可以替換父類
• 依賴倒置原則：要依賴于抽象，而不是具體實現(xiàn)；針對接口編程，不要針對實現(xiàn)編程
• 接口隔離原則：使用多個專門的接口比使用單一的總接口要好
• 組合重用原則：要盡量使用組合，而不是繼承關系到達重用目的
• 迪米特原則（最少知識原則）：一個對象應當對其他對象有盡可能少的了解

二十七、軟件測試

動態(tài)測試：計算機運行

• 白盒測試法
• 黑盒測試法
• 灰盒測試法（白+黑）

靜態(tài)測試：人工監(jiān)測和計算機輔助分析

• 桌前檢查
• 代碼審查
• 代碼走查

靜態(tài)測試都是做靜態(tài)分析

• 控制流分析：無法到達的語句等
• 數(shù)據(jù)流分析：引用未定義的變量、對以前未使用的變量再次賦值
• 接口分析：模塊之間接口的一致性、子程序和函數(shù)之間的接口一致性、函數(shù)形參與實參的數(shù)量、順序、類型的一致性
• 表達式分析：括號不匹配、數(shù)組引用越界、除數(shù)為零

27.1 白盒測試

白盒測試（結構測試）：主要用于單元測試階段

• 控制流測試（邏輯覆蓋測試）（語句覆蓋最弱，路徑測試覆蓋最強）
• 數(shù)據(jù)流測試
• 程序變異測試（錯誤驅動測試）

黑盒測試（功能測試）：主要用于集成測試、確認測試和系統(tǒng)測試階段

• 等價類劃分：不同等價類，揭示不同問題；有效等價類/無效等價類
• 邊界值分析：1<=x<=10,可取x的值為0,1,10和11作為測試數(shù)據(jù)
• 錯誤推測：依靠測試人員的經(jīng)驗和直覺
• 判定表：最適合描述在多個邏輯條件取值的組合所構成的復雜情況下，分別要執(zhí)行哪些不同的動作。
• 因果圖：根據(jù)輸入條件與輸出結果之間的因果關系來設計測試用例

27.2 測試階段

單元測試：依據(jù)詳細測試，模塊測試，模塊功能、性能、接口等

集成測試：依據(jù)概要設計，模塊間的接口

系統(tǒng)測試：依據(jù)需求文檔，在真實的環(huán)境下，驗證完整的軟件配置項能否和系統(tǒng)正確連接

確認測試：依據(jù)需求文檔，驗證軟件與需求的一致性。內部確認測試、Alpha測試、Beta測試、驗收測試，需要用戶參與

回歸測試：測試軟件變更之后，變更部分的正確性和對變更需求的符合性

系統(tǒng)測試

• 功能測試
• 性能測試
  • 負載測試：各種工作負載下系統(tǒng)的性能
  • 壓力測試（測上限）：系統(tǒng)的瓶頸或不能接受的性能點
  • 強度測試（測下限）：系統(tǒng)資源特別低的情況下運行
  • 容量測試（并發(fā)測試）：同時在線的最大用戶數(shù)
  • 可靠性測試：MTTF之類的參數(shù)
• 健壯性測試
• 用戶界面測試
• 安全性測試
• 安裝與反安裝測試

二十八、遺留系統(tǒng)演化策略

?

考慮遺留系統(tǒng)在業(yè)務價值和水平的高低

二十九、新舊系統(tǒng)的轉換策略

?

直接轉換：會先停止現(xiàn)有系統(tǒng)，再上新系統(tǒng)

并行轉換：老系統(tǒng)和新系統(tǒng)并存

分段轉換：轉換一部分

三十、數(shù)據(jù)轉換與遷移

文章來源地址http://www.zghlxwxcb.cn/news/detail-820173.html

三十一、軟件維護

• 可理解性：是指通過閱讀源碼和相關文檔，了解軟件的功能和如何運行的容易程度
• 可修改性：修改軟件的難易程度
• 可測試性：驗證軟件程序正確的難易程度
• 可靠性：一個軟件的可靠性越高，需要維護的概率就會越低
• 可移植性：是指將軟件從一個環(huán)境移植到新環(huán)境下正確運行的難易程度

三十二、軟件維護類型

• 正確性維護（修bug）：識別和糾正軟件錯誤與缺陷，測試不可能發(fā)現(xiàn)所有錯誤
• 適應性維護（應變）：指使應用軟件適應環(huán)境變化（外部環(huán)境、數(shù)據(jù)環(huán)境）而進行的修改
• 完善性維護（新需求）：擴充功能和改善性能而進行的修改
• 預防性維護（針對未來）：為了適應未來的軟硬件環(huán)境的變化，應主動增加預防性的新的功能，以使用系統(tǒng)適應各類變化而不被淘汰。經(jīng)典實例：專用改通用。

到了這里，關于軟考之軟件工程的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！