第一章 介紹

1.1 軟件的定義

答：

1.指令的集合（程序）通過這些指令來滿足預(yù)期的特性、功能、需求

2.數(shù)據(jù)結(jié)構(gòu)。使程序可以良好的使用信息

3.軟件描述信息。以硬拷貝和虛擬形式存在，用來描述程序的操作和使用

1.2 軟件與硬件的區(qū)別（軟件特征）

屬性軟件硬件

開發(fā)方式	開發(fā)或者工程獲得	以傳統(tǒng)方式制造
使用時(shí)間	不會(huì)磨損(wear out)(最本質(zhì)區(qū)別),而是退化(deterioriting)	會(huì)磨損
復(fù)用性	客戶定制,可復(fù)用程度低(盡管模塊化)	可復(fù)用程度高
替換	不存在備用部件	存在備用部件

雙重角色 既是產(chǎn)品也是產(chǎn)品交付的載體

Q:為什么軟件要更新?

A:新的商業(yè)需求，新的環(huán)境和技術(shù)，與其他軟件的兼容和交互，新的計(jì)算環(huán)境

1.3 軟件過程是什么？

軟件過程是工作產(chǎn)品構(gòu)建時(shí)所執(zhí)行的一系列活動(dòng),動(dòng)作和任務(wù)的集合.

• 活動(dòng) 實(shí)現(xiàn)寬泛目標(biāo)(如與利益相關(guān)者溝通)
• 動(dòng)作 如體系結(jié)構(gòu)設(shè)計(jì),包含很多任務(wù)
• 任務(wù) 小而具體,如一個(gè)單元測試

軟件過程定義了軟件工程化中采用的方法（框架活動(dòng)），但軟件工程還包括該過程中的應(yīng)用技術(shù)（技術(shù)方法和自動(dòng)化工具），軟件過程包含在軟件工程中。

1.4 軟件工程是什么？

軟件工程是建立和使用一套合理的工程原則,以便經(jīng)濟(jì)的獲得可靠的,可以在實(shí)際機(jī)器上高效運(yùn)行的軟件.

定義

將系統(tǒng)化、規(guī)范化、可量化的方法應(yīng)用于軟件的開發(fā)、運(yùn)行和維護(hù)），即：將工程化的方法應(yīng)用于軟件開發(fā)

以及對(duì)上述方法的研究

第二章 軟件過程

2.1 軟件工程的層次

軟件工程是層次化的結(jié)構(gòu)

• 工具 為Process過程和Method方法提供支持
• 方法 提供技術(shù)上的解決方法，指出如何構(gòu)建
• 過程 基礎(chǔ)，及時(shí)、合理地把技術(shù)結(jié)合在一起
• 質(zhì)量關(guān)注點(diǎn) 根基，質(zhì)量承諾

2.2 普適性活動(dòng)

• 軟件項(xiàng)目跟蹤和控制Software project management
• 技術(shù)評(píng)審Formal technical reviews
• 軟件質(zhì)量保障Software quality assurance
• 軟件配置管理Software configuration management
• 工作產(chǎn)品的準(zhǔn)備和生產(chǎn)Work product preparation and production
• 可復(fù)用管理Reusability management
• 測量Measurement
• 風(fēng)險(xiǎn)管理Risk management

2.3 過程評(píng)估和改進(jìn)（Capability maturity Model，CMM等）

• Standard CMMI Assessment Method for Process Improvement (SCAMPI)： 用于過程改進(jìn)的CMMI標(biāo)準(zhǔn)評(píng)估方法.

  分五個(gè)評(píng)估階段：起始、診斷、建立、行動(dòng)和學(xué)習(xí)

• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)：用于組織內(nèi)部過程改進(jìn)的CMM評(píng)估

  為評(píng)估軟件組織的相對(duì)成熟度提供診斷技術(shù)；使用SEI-CMM作為評(píng)估的基礎(chǔ)

• SPICE—The SPICE (ISO/IEC15504) ：軟件過程改進(jìn)和能力測定（software process improvement and capability determination）

  標(biāo)準(zhǔn)定義了軟件過程評(píng)估的一組需求。本標(biāo)準(zhǔn)的目的是幫助組織對(duì)任何定義的軟件過程的有效性進(jìn)行客觀的評(píng)估。

• ISO 9001:2000 for Software：國際標(biāo)準(zhǔn)化組織的軟件開發(fā)標(biāo)準(zhǔn)

  一種通用標(biāo)準(zhǔn)，適用于任何希望提高其提供的產(chǎn)品、系統(tǒng)或服務(wù)的總體質(zhì)量的組織。因此，本標(biāo)準(zhǔn)直接適用于軟件組織和公司。

• GB 國標(biāo)

CMM最先出現(xiàn)，但后來得到了改進(jìn)，并被CMMI所取代。

不同的三坐標(biāo)測量機(jī)存在重疊、矛盾、缺乏標(biāo)準(zhǔn)化等問題。CMMI后來解決了這些問題。

最初，CMM專門描述軟件工程，而CMMI描述集成過程和規(guī)程，因?yàn)樗瑫r(shí)適用于軟件和系統(tǒng)工程。

CMM/CMMI適用于大型項(xiàng)目。關(guān)注過程，而不是軟件開發(fā)的人員和技術(shù)方面，這意味著實(shí)現(xiàn)它們并不能保證項(xiàng)目成功。

CMM/CMMI是一個(gè)綜合的過程元模型，它描述了成熟軟件過程中應(yīng)該出現(xiàn)的特定目標(biāo)、實(shí)踐和能力

2.4 過程流（線性、迭代、演化、并行）

線性過程流：從溝通到部署順序執(zhí)行五個(gè)框架活動(dòng)

迭代過程流：在執(zhí)行下一個(gè)活動(dòng)前，重復(fù)執(zhí)行之前的一個(gè)或多個(gè)活動(dòng)

演化過程流：采用循環(huán)的方式執(zhí)行各個(gè)活動(dòng)

并行過程流：將一個(gè)或多個(gè)活動(dòng)與其他活動(dòng)并行執(zhí)行

2.5 過程模型

2.5.1 瀑布模型

典型生命周期模型 溝通、策劃、建模、構(gòu)建、部署

好處壞處

適用于：需求固定，工作將以線性方式進(jìn)行到完成	真正的項(xiàng)目很少遵循順序流程。隨著項(xiàng)目團(tuán)隊(duì)的進(jìn)行，更改可能會(huì)導(dǎo)致混亂
	要求客戶明確地陳述所有需求，并且難以適應(yīng)許多項(xiàng)目開始時(shí)所存在的自然不確定性
	最后才能看到可執(zhí)行程序，如果系統(tǒng)存在重大缺陷，會(huì)導(dǎo)致災(zāi)難后果

V-模型 與之相似 提供了將驗(yàn)證確認(rèn)動(dòng)作應(yīng)用于早期軟件工程中的方法

2.5.2 增量模型

優(yōu)點(diǎn)缺點(diǎn)

克服人手不足	關(guān)注每一個(gè)增量的操作產(chǎn)品的交付。早期的增量很容易被“忽略”。
技術(shù)風(fēng)險(xiǎn)控制
線性（每個(gè)增量按照瀑布模型進(jìn)行管理）+并行
每個(gè)增量都是可提交運(yùn)行的版本，（第一個(gè)增量往往是核心產(chǎn)品core product

2.5.3 原型模型

優(yōu)點(diǎn)缺點(diǎn)

當(dāng)需求很模糊時(shí)適用	原型常常會(huì)被拋棄，而不是在其上繼續(xù)開發(fā)（增加成本）
適用高風(fēng)險(xiǎn)	一些湊合的技術(shù)和算法可能會(huì)遺留在最終系統(tǒng)中

2.5.4 螺旋模型（風(fēng)險(xiǎn)驅(qū)動(dòng)的過程模型）

螺旋模型是一種演化過程模型，它結(jié)合了原型的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性，注重風(fēng)險(xiǎn)控制（里程碑），適合大型項(xiàng)目開發(fā)

螺旋模型兩個(gè)顯著特點(diǎn)：

• 采用循環(huán)的方式逐步加深系統(tǒng)定義和實(shí)現(xiàn)的深度
• 確定一系列里程碑，確保利益相關(guān)者都支持可行的和令人滿意的系統(tǒng)解決方案

在每一次迭代的過程中，都要考慮風(fēng)險(xiǎn)、標(biāo)記里程碑

優(yōu)點(diǎn)缺點(diǎn)

使用原型作為風(fēng)險(xiǎn)降低機(jī)制，任何時(shí)候都可以應(yīng)用原型模型方法	很難說服客戶項(xiàng)目演進(jìn)的方法是可控的
開發(fā)大型系統(tǒng)和軟件的現(xiàn)實(shí)方法。（開發(fā)人員和客戶更好地理解和應(yīng)對(duì)每一個(gè)過程中的風(fēng)險(xiǎn)）	依賴風(fēng)險(xiǎn)專家來保證項(xiàng)目成功，同樣有風(fēng)險(xiǎn)

2.5.5 并行開發(fā)模型（concurrent development model）

協(xié)同開發(fā)模型，又叫做協(xié)同工程?？梢员硎疽幌盗锌蚣芑顒?dòng)，軟件工程動(dòng)作和任務(wù)以及相應(yīng)的狀態(tài)。協(xié)同模型更適合于不同的工程團(tuán)隊(duì)共同開發(fā)的系統(tǒng)工程項(xiàng)目。尤其是大型的軟件公司或者是跨國公司往往要用到這種模型來開發(fā)項(xiàng)目。

其它活動(dòng)（比如溝通或編碼等）、動(dòng)作、任務(wù)都可以如右圖方式表示，它們同時(shí)存在并處于不同的狀態(tài)

2.5.6 演化模型

軟件總是在持續(xù)改變，這些改變通常要求在非常短的期限內(nèi)完成，在許多情況下，及時(shí)投入市場是最重要的要求（如果錯(cuò)過了，軟件本身可能會(huì)變得毫無意義）。

軟件團(tuán)隊(duì)面臨的挑戰(zhàn)是在這些關(guān)鍵項(xiàng)目、產(chǎn)品參數(shù)和客戶滿意度之間建立適當(dāng)?shù)钠胶?/p>

在許多情況下，上市時(shí)間是最重要的管理要求。

如果錯(cuò)過了一個(gè)市場窗口，軟件項(xiàng)目本身可能毫無意義。

缺陷

• 不確定性
• 演化速度的控制
• 應(yīng)側(cè)重靈活性與擴(kuò)展性

演化模型是迭代的過程模型

• 原型模型
• 螺旋模型
• 協(xié)同模型

2.5.7 其他模型

• ? 基于構(gòu)建的開發(fā)
• ? 形式化方法模型
• ? AOSD（Aspect-Oriented Software Development）

2.6 統(tǒng)一過程模型（迭代增量過程，用UML進(jìn)行面向?qū)ο筌浖こ痰目蚣芎瓦^程）

“用例驅(qū)動(dòng)、以架構(gòu)為核心、迭代和增量”的軟件開發(fā)過程，關(guān)注風(fēng)險(xiǎn)

統(tǒng)一過程模型嘗試從傳統(tǒng)的軟件過程模型中挖掘最好的特征和性質(zhì)，但是以敏捷軟件開發(fā)中最好的原則來實(shí)現(xiàn)

統(tǒng)一過程模型是使用UML進(jìn)行面向?qū)ο筌浖浖_發(fā)的理想的過程模型

第三章 敏捷開發(fā)

3.1 敏捷是什么？

最簡而言之：快速、增量（迭代）

• 快速交付產(chǎn)品
• 對(duì)變化的有效響應(yīng)
• 客戶加入團(tuán)隊(duì)，所有利益相關(guān)者之間的有效溝通
• 項(xiàng)目計(jì)劃必須靈活
• 一個(gè)自組織團(tuán)隊(duì)，便于溝通

3.2 敏捷宣言（Manifesto for Agile）

敏捷傳統(tǒng)

個(gè)人與交互	過程和工具
可運(yùn)行軟件	繁復(fù)文檔
客戶合作	合同談判
響應(yīng)變更	遵循計(jì)劃

3.3 極限編程（XP）

3.3.1 極限編程框架活動(dòng)

策劃

設(shè)計(jì) KIS, CRC

編碼 結(jié)對(duì)編碼

測試 關(guān)注重要的、易出錯(cuò)的地方，進(jìn)行回歸測試，80%錯(cuò)誤發(fā)生在20%代碼中

3.3.2 極限編程的關(guān)鍵

五個(gè)要素

溝通（緊密的非正式口頭協(xié)作，避免大量文檔）

簡單（只為眼前的需要而設(shè)計(jì)，不考慮未來的需要）

反饋（來自實(shí)施的軟件本身、客戶、其他軟件團(tuán)隊(duì)成員）

勇氣（今天的設(shè)計(jì)意味著未來的需求可能會(huì)發(fā)生巨大的變化，因此需要大量的返工）

尊重（IT成員之間、利益相關(guān)者之間）

3.4 其他敏捷過程

Scrum

DSDM-Dynamic Systems Development Method

AM

AUP

第四章 需求工程

4.1 需求工程的定義

• 需求工程是指致力于不斷理解需求的大量任務(wù)和技術(shù)。
• 建立了從設(shè)計(jì)到構(gòu)建的橋梁
• 從軟件過程的角度來看，需求工程是一個(gè)軟件工程動(dòng)作，開始于溝通活動(dòng)并持續(xù)到建?；顒?dòng)

4.2 質(zhì)量功能部署（quality funtion development，QFD）

將用戶要求轉(zhuǎn)換成軟件技術(shù)需求。

QFD概念可應(yīng)用于整個(gè)軟件過程（不僅僅在需求收集中）

三種需求

• 常規(guī)需求
• 預(yù)期需求
• 興奮需求

四種展開

功能展開

信息展開

任務(wù)展開

價(jià)值評(píng)估

4.3 ERD圖

橢圓表示屬性，加在長方形上

4.4 用例圖

4.5 需求工程的目標(biāo)

起始、獲取、細(xì)化、協(xié)商、規(guī)格說明、驗(yàn)證、需求管理

4.6 需求分析建模原則（rule of thumb）

關(guān)注可見需求，不要陷入細(xì)節(jié)

增加對(duì)軟件需求主體的理解

有些非功能的模型可以延后到設(shè)計(jì)階段完成

低耦合

確認(rèn)需求模型對(duì)所有利益相關(guān)者帶來價(jià)值

簡潔

4.7 需求建模模型

4.7.1 基于場景的建模

用例：

用戶故事： 描述對(duì)用戶有價(jià)值的功能,好的用戶故事應(yīng)該包括角色、功能和商業(yè)價(jià)值三個(gè)要素

1.角色：誰要使用這個(gè)功能。

2.功能：需要完成什么樣的功能。

3.價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來什么樣的價(jià)值。

4.7.2 基于類的建模（class-modeling， CRC）

類圖、協(xié)作圖

類-職責(zé)-協(xié)作者

CRC建模提供了一個(gè)簡單方法，可以識(shí)別和組織與系統(tǒng)或產(chǎn)品需求相關(guān)的類

職責(zé) 封裝在類中的屬性和操作

協(xié)作者 完成某個(gè)職責(zé)的其它協(xié)作的類

類之間關(guān)系

• Aggregate聚合**(is-part-of)**

（強(qiáng)關(guān)聯(lián)）

• Associate關(guān)聯(lián)**(has-knowledge-of)**

（只有控制面板和傳感器協(xié)作，才能確定傳感器狀態(tài)）

（雙向）

• Dependency依賴**(depends-upon)**

（單向）

4.7.3 面向流的建模

DFD，數(shù)據(jù)模型，數(shù)據(jù)流圖

4.7.4 行為模型

狀態(tài)圖、序列圖

• 狀態(tài)圖描述系統(tǒng)的狀態(tài)，并顯示事件如何影響系統(tǒng)狀態(tài)。
• 序列圖指示事件如何導(dǎo)致從對(duì)象到對(duì)象的轉(zhuǎn)換。

4.8 UML是什么

4.9 分析建模所使用的圖

• 用例圖

• 活動(dòng)圖

• 類圖

• 狀態(tài)圖

• 部署圖

• 序列圖

• 協(xié)作圖

第五章 設(shè)計(jì)概念

5.1 設(shè)計(jì)概念

模塊化

信息隱藏

關(guān)注點(diǎn)分離

重構(gòu)

內(nèi)聚（cohesion）

耦合（coupling）

5.2 面向?qū)ο蟾拍?/h3>

類、屬性、行為

多態(tài)性

封裝

繼承

5.3 質(zhì)量屬性（FURPS）

功能性Functional

易用性Usability

可靠性Reliability

性能Performance

可支持性Supportability

5.4 DFD

變換流/事務(wù)流

使用數(shù)據(jù)流映射

舉例

5.5 四個(gè)設(shè)計(jì)模塊

包括數(shù)據(jù)設(shè)計(jì)、架構(gòu)設(shè)計(jì)、界面設(shè)計(jì)、部件設(shè)計(jì)、（部署設(shè)計(jì)）

5.5.1 數(shù)據(jù)設(shè)計(jì)

5.5.2 架構(gòu)設(shè)計(jì)

架構(gòu)設(shè)計(jì)包括軟件構(gòu)件，構(gòu)件的屬性和構(gòu)件之間的相互關(guān)系

架構(gòu)設(shè)計(jì)的重要性

有助于各方的交流

突出早期的設(shè)計(jì)，對(duì)其后工作很重要（打好設(shè)計(jì)的根基）

建立一個(gè)相對(duì)小的、易于理解的模型，其描述了系統(tǒng)如何構(gòu)成及構(gòu)件如何一起工作

架構(gòu)的風(fēng)格流派

• 以數(shù)據(jù)為中心架構(gòu)
• 數(shù)據(jù)流架構(gòu)
• 調(diào)用和返回架構(gòu)
• 面向?qū)ο蠹軜?gòu)
• 層次化架構(gòu)

5.5.3 界面設(shè)計(jì)

黃金原則

用戶操作控制

減少用戶的記憶和負(fù)擔(dān)

保持界面的一致性

用戶界面設(shè)計(jì)模型

• 用戶模型 所有終端用戶的畫像
• 設(shè)計(jì)模型 用戶模型的設(shè)計(jì)實(shí)現(xiàn)
• 感知模型 界面給用戶的印象
• 實(shí)施模型 界面的外觀和給用戶的感覺與描述的支持文檔相符合

用戶界面設(shè)計(jì)過程

• 界面分析和建模
• 界面設(shè)計(jì)
• 界面構(gòu)建
• 界面確認(rèn)

界面分析和建模

• 用戶分析
• 任務(wù)分析
• 展出內(nèi)容分析
• 工作環(huán)境分析

界面設(shè)計(jì)

使用接口分析期間獲得的信息定義接口對(duì)象和操作

定義將導(dǎo)致用戶界面改變的事件,對(duì)這種行為進(jìn)行建模

將每個(gè)接口狀態(tài)描述為它將實(shí)際呈現(xiàn)給終端用戶的樣子

指示用戶通過界面提供的信息理解系統(tǒng)的狀態(tài)

5.5.4 部件設(shè)計(jì)

構(gòu)件是模塊化的、可部署的和可替換的部件，該部件封裝了操作實(shí)現(xiàn)和接口

從面向?qū)ο蠼嵌瓤床考?/p>

從方便角度看部件是

決策表Decision Table

部件設(shè)計(jì)原則

• 開閉原則 （open-close principle, OCP）
• 替換原則 (the liskov substitution, LSP)
• 依賴倒置原則(dependency inversion principle, DIP)
• 接口分離原則(the interface segregation principle, ISP)

5.5.5（部署設(shè)計(jì)）

第六章 測試

6.1 測試是什么

測試是為了在將軟件交付給用戶之前發(fā)現(xiàn)軟件設(shè)計(jì)和實(shí)現(xiàn)過程中因疏忽所造成的錯(cuò)誤

6.2 測試策略

• 為了執(zhí)行有效的測試,應(yīng)該進(jìn)行有效的技術(shù)審查.這樣可以在測試開始之前消除許多錯(cuò)誤
• 測試是從部件級(jí)開始并且向外朝著整個(gè)基于計(jì)算機(jī)的系統(tǒng)的集成測試
• 不同的測試方法適用于不同時(shí)間點(diǎn)的不同軟件工程方法
• 測試是由軟件開發(fā)者和一個(gè)獨(dú)立的測試組執(zhí)行的
• 測試和調(diào)試是不同的活動(dòng),但任何測試策略都應(yīng)該適應(yīng)調(diào)試

6.3 測試方法

單元測試

集成測試

• 自頂向下
• 自底向上
• 三明治測試

驗(yàn)證測試

• 軟件的驗(yàn)證是通過一系列證明符合要求的測試來實(shí)現(xiàn)的.設(shè)計(jì)測試計(jì)劃和測試用例都是為了確保所有的功能需求得到滿足,所有的行為體征和屬性得到實(shí)現(xiàn),所有的內(nèi)容都是準(zhǔn)確的,并且正確的呈現(xiàn),所有的性能需求都得到了滿足,文檔是正確的,并且可用性和其他需求都得到了滿足
• 配置檢查
• 驗(yàn)收測試(alpha/beta testinng)

系統(tǒng)測試

• 恢復(fù)測試
• 安全性測試
• 壓力測試
• 性能測試
• 部署測試
• 配置測試

黑盒測試與白盒測試

• 黑盒測試

  就是功能測試,從外部執(zhí)行測試用例,用以驗(yàn)證待測功能的正確性,而不考慮軟件內(nèi)部處理邏輯,外部測試

• 白盒測試

  也叫玻璃盒測試,是一種測試用例設(shè)計(jì)方法.它利用作為構(gòu)件層設(shè)計(jì)的一部分所描述的控制結(jié)構(gòu)來生成測試用例.白盒測試是基于過程細(xì)節(jié)的封閉測試.測試構(gòu)建內(nèi)部的數(shù)據(jù)結(jié)構(gòu),算法流程與接口,內(nèi)部測試.

其他測試

回歸測試\冒煙測試\調(diào)試|調(diào)試方法

6.4 面向?qū)ο蟮臏y試

• 面向?qū)ο蟮膯卧獪y試

  單元的概念改變,最小的可測試單元是封裝的類,單個(gè)操作不能再單獨(dú)測試,而是作為類的一部分

• 面向?qū)ο蟮募蓽y試

  集群測試是OO軟件集成測試的一個(gè)步驟,定義一個(gè)協(xié)作類集群(通過檢查CRC和對(duì)象關(guān)系模型確定),是通過測試用例來實(shí)現(xiàn)的,這些測試用例試圖發(fā)現(xiàn)協(xié)作中的錯(cuò)誤.

  兩種集成方法

  • 基于線程的測試集成了響應(yīng)系統(tǒng)使用的一個(gè)輸入或事件所需的一組類.
  • 基于使用的測試通過測試那些很少使用服務(wù)類在獨(dú)立的類測試后,下一層的類稱為從屬類

6.5 環(huán)復(fù)雜度(cyclomatic complexity)

V(G) = E(edge) - N(Node) + 2

V(G) = P(選擇節(jié)點(diǎn)數(shù)) + 1

總結(jié)

以上是生活随笔為你收集整理的【期末复习】软件工程知识总结（四川大学）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。