一、背景知識：
軟件開發(fā)的基本過程：
需求定義→軟件設(shè)計→軟件實(shí)現(xiàn)→軟件測試→軟件維護(hù)
軟件的定義：
軟件=程序+數(shù)據(jù)+文檔
程序：可以按照設(shè)計好的功能和性能要求執(zhí)行的指令序列
數(shù)據(jù)：程序能正確處理信息的數(shù)據(jù)結(jié)構(gòu)
文檔：與程序的開發(fā)、維護(hù)、使用有關(guān)的圖文資料
軟件的特點(diǎn)：
- 包含個人因素的大規(guī)模知識型工作
- 有工具輔助的軟件開發(fā)也尚未實(shí)現(xiàn)自動化（即無法像硬件加工一樣，機(jī)械組裝已有部件，軟件開發(fā)還未達(dá)到組裝已有模塊的程度）
- 對開發(fā)和運(yùn)行的計算機(jī)軟硬件環(huán)境具有依賴性
- 需求往往在變更，開發(fā)進(jìn)度難估算
- 軟件測試?yán)щy，覆蓋所有路徑的測試難實(shí)現(xiàn)。軟件測試只能證明軟件中有缺陷，不能證明軟件中沒有缺陷。
- 軟件不會損耗，（參考硬件的磨損和老化），軟件維護(hù)不再具有經(jīng)濟(jì)性時，軟件即被淘汰
軟件危機(jī)：
- 1965年——1985年，20世紀(jì)60——80年代
- 于1968年提出
- 催生了軟件工程這一學(xué)科
- 沒有化解軟件危機(jī)的靈丹妙藥，已知的技術(shù)和方法都是進(jìn)一步改進(jìn)
SWEBOK（軟件工程知識體系指南）
PDCA環(huán)（戴明環(huán)）：
二、軟件過程：
以質(zhì)量為中心，以軟件工程，方法，工具為三要素。其中軟件過程是基礎(chǔ)，是聯(lián)系各層的橋梁，工具為過程和方法提供支持。
軟件過程的定義：軟件過程定義了軟件開發(fā)中的一系列活動，所以過程都具有下列活動：
- 溝通
- 建模
- 計劃
- 構(gòu)造
- 部署
- 項(xiàng)目管理（貫穿于以上所有活動）
軟件生命周期：
- 定義時期：問題定義，可行性研究，需求分析
- 開發(fā)時期：概要設(shè)計，詳細(xì)設(shè)計，編碼，測試
- 運(yùn)行/維護(hù)時期
軟件過程模型：
- 模型不是過程的直接描述，而是過程的抽象?？梢杂糜诮忉屲浖a(chǎn)品不同的開發(fā)方法。
- 從項(xiàng)目需求定義到運(yùn)行維護(hù)為止，跨越整個生命周期的過程，活動和任務(wù)的結(jié)構(gòu)框架。
- 也被稱為：軟件生命周期模型，軟件開發(fā)模型，軟件工程范型
瀑布模型：
- 20世紀(jì)80年代之前被廣泛使用，因此被稱為經(jīng)典的生命周期模型。
- 線性模型：軟件開發(fā)過程與生命周期是一致的，規(guī)定了各項(xiàng)工程活動的自上而下，逐級下落的次序。
- 以文檔為驅(qū)動
傳統(tǒng)的瀑布模型：
- 各個階段都按順序執(zhí)行
- 每個階段完成規(guī)定的文檔
- 每個階段結(jié)束有一個驗(yàn)證環(huán)節(jié)，只有通過驗(yàn)證才能進(jìn)入下一個階段
- 階段間具有順序性和依賴性：前一階段的輸出文檔就是后一階段的輸入文檔
- 推遲實(shí)現(xiàn)的觀點(diǎn)（重要思想）：區(qū)分開邏輯設(shè)計和物理設(shè)計，推遲程序的物理實(shí)現(xiàn)
- 質(zhì)量保證的觀點(diǎn)：每個階段必須完成規(guī)定的文檔，并在階段結(jié)束前進(jìn)行審核
實(shí)際的（帶反饋的）瀑布模型：
若后面的階段發(fā)現(xiàn)前面階段的錯誤，則返回前面階段進(jìn)行修改。
瀑布模型的優(yōu)缺點(diǎn)：
- 每個階段交出的作品都是經(jīng)過驗(yàn)證的，每個階段都有文檔
- 能較好的與其它過程模型結(jié)合
- 不夠靈活：下一階段開始前，當(dāng)前階段的結(jié)果需固定下來
- 整體性太強(qiáng)：分析階段出現(xiàn)任何失誤，交互用戶后才能發(fā)現(xiàn)，增加了開發(fā)的風(fēng)險
- 嚴(yán)格文檔驅(qū)動，較為繁瑣
- 開發(fā)早期投入大量成本，難以應(yīng)對用戶需求變更
瀑布模型適用于：需求很明確且將來沒有太大改變的情況。大型項(xiàng)目中一些部分的開發(fā)。
演化模型（分為原型模型和并行開發(fā)模型）：
首先實(shí)現(xiàn)軟件最核心，最重要的功能，待用戶進(jìn)一步了解軟件后再實(shí)現(xiàn)細(xì)節(jié)。
相比瀑布模型能更高效地生產(chǎn)出符合要求的系統(tǒng)，靈活面對客戶需求變更。
小型和中型系統(tǒng)：演化模型
大型系統(tǒng)：混合瀑布模型和演化模型（采用演化模型難以建立穩(wěn)定的系統(tǒng)架構(gòu)，不利于團(tuán)隊工作整合）
原型模型：
快速建立起可以在計算機(jī)上運(yùn)行的程序，是最終產(chǎn)品的子集。
與用戶確定下原型以后，再開始完整的開發(fā)過程。
原型確定后，下面的開發(fā)過程基本不帶反饋。
原型模型的優(yōu)缺點(diǎn)：
- 有助于了解用戶的真正需求
- 不會因?yàn)樾枨笠?guī)格說明文檔的錯誤進(jìn)行大規(guī)模返工
- 開發(fā)人員在實(shí)現(xiàn)原型系統(tǒng)學(xué)到了東西，后續(xù)出錯率降低
- 為了快速開發(fā)出原型，開發(fā)人員可能不會長遠(yuǎn)考慮，而降低質(zhì)量，放棄部分需求
并行開發(fā)模型（并發(fā)模型）：
所有活動同時存在但是處于不同狀態(tài)。
增量過程模型（分為增量模型，RAD模型，螺旋模型）：
非整體開發(fā)的模型，從部分需求出發(fā)，建立一個不完整的系統(tǒng)——測試——添加增量。
增量模型：
增量：小而可用的軟件
- 增量模型與原型模型的不同在于：每個增量都是可運(yùn)行的產(chǎn)品，能完成特定功能。
- 每個增量的開發(fā)可以采用瀑布模型或快速原型模型。
- 第一個增量通常是核心產(chǎn)品。
- 在前面增量的基礎(chǔ)上開發(fā)后面的增量。
- 一個增量部署后，進(jìn)入下一次迭代，直到出現(xiàn)最終產(chǎn)品。
- XP極限編程：基于小增量的開發(fā)和交付
增量模型的優(yōu)缺點(diǎn)：
- 無需完整需求，只要一個增量包，開發(fā)即可進(jìn)行。
- 項(xiàng)目初始階段無需大量人力資源，被認(rèn)可后才投入。
- 不能在ddl前完成項(xiàng)目，核心增量產(chǎn)品也能交付。
- 很難根據(jù)需求給出大小合適的增量。
- 加入新增量不能破壞已開發(fā)出的產(chǎn)品。
- 需要比瀑布和原型模型更精心的設(shè)計。
RAD（Rapid Application Development）快速應(yīng)用開發(fā)模型：
- 強(qiáng)調(diào)短暫的開發(fā)周期，瀑布模型的“高速”變體
- 主要用于信息系統(tǒng)的開發(fā)
- 包括業(yè)務(wù)建模，數(shù)據(jù)建模，過程建模
- 需要足夠的人力資源
- 并非所有系統(tǒng)都適合，不能合理模塊化和技術(shù)風(fēng)險高的系統(tǒng)都不適合
螺旋模型：
結(jié)合了瀑布模型和原型模型，加入了兩種模型都沒有的風(fēng)險分析。
強(qiáng)調(diào)風(fēng)險管理：適用于大型系統(tǒng)的開發(fā)。
基本思想：使用原型及其它方法來盡量降低風(fēng)險。
理解為：在每個階段都加入風(fēng)險分析的快速原型模型
特點(diǎn)：
- 能應(yīng)對開發(fā)過程中的各種變化。
- 僅適用于內(nèi)部項(xiàng)目，不能用于合同性的軟件開發(fā)，因?yàn)檫^程中有風(fēng)險評估。
- 風(fēng)險驅(qū)動：要求開發(fā)人員具有豐富的風(fēng)險評估經(jīng)驗(yàn)和專業(yè)知識。
- 只適用于大型軟件的開發(fā)。
基于構(gòu)件的模型：
- 構(gòu)件（也稱組件）：支持軟件重用（復(fù)用）Software Reuse
- 以重用為導(dǎo)向，以大量可用的組件及一些集成框架為基礎(chǔ)。
- 根據(jù)需求規(guī)格搜索可重用的組件，通常情況下沒有，則對組件加以修改或構(gòu)造新的組件，再將組件進(jìn)行開發(fā)和集成。
敏捷過程模型：
基本原理和開發(fā)過程的結(jié)合。
如何選擇過程模型？
- 各種過程模型并不互相排斥，在開發(fā)中通常一起使用。
- 軟件過程決定了軟件產(chǎn)品的質(zhì)量。
- 可根據(jù)實(shí)際創(chuàng)造新的模型。
軟件開發(fā)中的兩種傾向：以產(chǎn)品為中心/以過程為中心（以過程為中心更能生產(chǎn)高質(zhì)量的產(chǎn)品）
能力成熟度模型：
軟件過程成熟度：1.角色與職責(zé) 2.處理變更的方式 3.對發(fā)生問題的反應(yīng) 4.可信性 5.對工作人員的獎勵 6.預(yù)見性
CMM(Capibility Maturity Model)：能力成熟度模型：
- 最早提出時，它指的是軟件過程能力成熟度模型。
- 按照成熟度劃分為5個等級。1級最低，5級最高。
SEI(Software Engineering Institute)：軟件工程研究所（發(fā)布CMM，CMMI）
CMMI(Capibility Maturity Model Integration)：能力成熟度模型集成
CMMI 1.2：當(dāng)前實(shí)施的有效版本
- 將成熟度分為5個等級，只有達(dá)到某個等級后，才能進(jìn)入下一等級。
- 只定義要達(dá)到什么目標(biāo)，不定義如何達(dá)到。
- 初始級：依賴于有能力的人
- 可重復(fù)級：有基本的項(xiàng)目管理
- 已定義級：過程標(biāo)準(zhǔn)化
- 量化管理級：收集分析數(shù)據(jù)，來支持決策。制定量化目標(biāo)，以此作為管理過程的標(biāo)準(zhǔn)
- 優(yōu)化級：持續(xù)地改進(jìn)過程
過程域（Process Area PA）:
CMMI每個等級都規(guī)定了過程域。即若干個值得重視的軟件過程。
