每天學(xué)習(xí)一點(diǎn)點(diǎn)，距離考試通過成功拿證就更進(jìn)一點(diǎn)點(diǎn)。本站編輯為大家整理了軟考系統(tǒng)架構(gòu)設(shè)計師考試中關(guān)于軟件工程基礎(chǔ)知識部分的常見考點(diǎn)，快來一起學(xué)習(xí)吧。

溫馨提示：為了方便考生備考，右側(cè)整理了軟考系統(tǒng)架構(gòu)設(shè)計師備考資料，點(diǎn)擊資料下載區(qū)域可進(jìn)行免費(fèi)下載，希望對大家備考有所幫助！

一、軟件工程定義

1.軟件工程定義

核心定義：軟件工程是應(yīng)用系統(tǒng)性、規(guī)范化、可量化方法開發(fā)、運(yùn)行和維護(hù)軟件的學(xué)科，涵蓋計算機(jī)科學(xué)、數(shù)學(xué)、管理科學(xué)等多領(lǐng)域知識。其核心目標(biāo)是通過工程化手段解決軟件危機(jī)，提升軟件質(zhì)量(功能性、可靠性、可維護(hù)性)并控制開發(fā)成本與周期。

關(guān)鍵特征：

系統(tǒng)化：遵循PDCA循環(huán)(計劃→開發(fā)→確認(rèn)→演進(jìn))

可量化：引入度量指標(biāo)(如代碼復(fù)雜度、缺陷密度)實(shí)現(xiàn)過程控制

標(biāo)準(zhǔn)化：采用ISO 9000、CMMI等國際標(biāo)準(zhǔn)規(guī)范流程

2.軟件過程模型

瀑布模型：

階段：需求→設(shè)計→編碼→測試→維護(hù)(嚴(yán)格順序)

適用場景：需求明確、技術(shù)成熟的中小型項(xiàng)目

局限性：變更成本高(需求凍結(jié)后修改代價大)、測試滯后(僅在后期介入)

增量模型：

特點(diǎn)：分階段交付功能模塊(如先核心功能再擴(kuò)展)

優(yōu)勢：降低風(fēng)險、快速響應(yīng)部分用戶需求

挑戰(zhàn)：需高度模塊化設(shè)計，架構(gòu)需具備擴(kuò)展性

螺旋模型：

核心機(jī)制：迭代周期=風(fēng)險分析→原型開發(fā)→用戶評估→計劃調(diào)整

適用場景：大型復(fù)雜系統(tǒng)(如國防、金融核心系統(tǒng))，強(qiáng)調(diào)風(fēng)險驅(qū)動

V模型：

測試對應(yīng)關(guān)系：需求↔驗(yàn)收測試、設(shè)計↔系統(tǒng)測試、編碼↔單元測試

價值：強(qiáng)調(diào)測試的早期介入，提升缺陷發(fā)現(xiàn)效率

3.敏捷模型

四大價值觀：個體與互動 > 流程工具;可運(yùn)行軟件 > 詳盡文檔;客戶協(xié)作 > 合同談判;響應(yīng)變化 > 遵循計劃

Scrum框架：角色：Product Owner(需求優(yōu)先級)、Scrum Master(流程協(xié)調(diào))、開發(fā)團(tuán)隊(duì)(跨職能)

工件：Product Backlog(需求池)、Sprint Backlog(迭代任務(wù))、增量交付物

事件：每日站會(15分鐘)、Sprint評審會(演示成果)、回顧會(改進(jìn)流程)

極限編程(XP)：

實(shí)踐：持續(xù)集成(每日構(gòu)建)、測試驅(qū)動開發(fā)(TDD)、結(jié)對編程(知識共享)

適用性：小型團(tuán)隊(duì)(<10人)、需求頻繁變更場景

4.統(tǒng)一過程模型(RUP)

四大階段：

初始階段：確定業(yè)務(wù)目標(biāo)，識別關(guān)鍵用例(如電商系統(tǒng)的訂單處理)

細(xì)化階段：建立架構(gòu)基線(如微服務(wù)架構(gòu)設(shè)計)

構(gòu)造階段：增量開發(fā)(分模塊并行編碼)

交付階段：用戶驗(yàn)收測試(UAT)與部署

核心優(yōu)勢：

用例驅(qū)動：以用戶場景為核心設(shè)計功能

架構(gòu)為中心：通過4+1視圖模型(邏輯/開發(fā)/進(jìn)程/物理+用例)描述系統(tǒng)

5.軟件能力成熟度模型(CMMI)

成熟度等級：

初始級：依賴個人能力，過程不可預(yù)測

可重復(fù)級：制度化項(xiàng)目管理(如需求管理、項(xiàng)目計劃)

已定義級：標(biāo)準(zhǔn)化組織級過程(如SEPG制定規(guī)范)

已管理級：量化控制(如缺陷密度≤0.5/千行代碼)

優(yōu)化級：持續(xù)改進(jìn)(引入六西格瑪方法)

關(guān)鍵過程域(KPA)：

需求管理(RM)、項(xiàng)目監(jiān)督與控制(PMC)、過程與產(chǎn)品質(zhì)量保證(PPQA)

二、需求工程

1.需求獲取

方法技術(shù)：

用戶訪談：結(jié)構(gòu)化問卷 vs. 開放式討論(適用于不同用戶類型)

原型法：快速構(gòu)建低保真原型驗(yàn)證需求(如Axure制作界面草圖)

觀察法：現(xiàn)場觀摩業(yè)務(wù)流程(如銀行柜臺操作流程)

需求分類：

功能性需求：系統(tǒng)應(yīng)提供的服務(wù)(如用戶登錄、支付功能)

非功能性需求：性能(響應(yīng)時間<2秒)、安全性(SSL加密)、可維護(hù)性(模塊化設(shè)計)

2.需求變更

變更管理流程：

申請：填寫變更請求單(CRF)，描述變更內(nèi)容及影響

影響分析：評估對進(jìn)度、成本、質(zhì)量的影響(如導(dǎo)致項(xiàng)目延期2周)

CCB評審：變更控制委員會決策(需包含客戶代表、項(xiàng)目經(jīng)理、架構(gòu)師)

實(shí)施與驗(yàn)證：更新需求文檔并重新測試

基線管理：通過配置管理工具(如Git)凍結(jié)需求版本，記錄變更歷史

3.需求追蹤

追蹤矩陣(RTM)：

縱向追蹤：需求ID → 設(shè)計模塊 → 測試用例

橫向追蹤：覆蓋度分析(如需求覆蓋率≥95%)

工具支持：JIRA、DOORS等需求管理平臺

三、系統(tǒng)分析與設(shè)計

1.結(jié)構(gòu)化方法

核心工具：

數(shù)據(jù)流圖(DFD)：分層描述數(shù)據(jù)流動(0級圖→1級圖→n級圖)

結(jié)構(gòu)化語言：偽代碼描述處理邏輯(如“IF 余額≥金額 THEN 允許支付”)

模塊化原則：高內(nèi)聚(單一職責(zé))、低耦合(接口標(biāo)準(zhǔn)化)

2.面向?qū)ο蠓椒?/strong>