01.重構(gòu)：敏捷方法，簡化構(gòu)建設(shè)計(jì)，重新組織
敏捷方法中，重構(gòu)是一種重新組織技術(shù)，重新審視需求和設(shè)計(jì)，重新明確地描述它們以符合新的和現(xiàn)有的需求，可以簡化構(gòu)件的設(shè)計(jì)而無需改變其功能或行為。
02.基于構(gòu)建：合格性驗(yàn)證
基于構(gòu)件的軟件開發(fā)，主要強(qiáng)調(diào)在構(gòu)建軟件系統(tǒng)時(shí)復(fù)用已有的軟件“構(gòu)件”，在檢索到可以使用的構(gòu)件后，需要針對新系統(tǒng)的需求對構(gòu)件進(jìn)行合格性檢驗(yàn)、適應(yīng)性修改，然后集成到新系統(tǒng)中。
03.瀑布模型：軟件需求明確
常見的軟件生存周期模型有瀑布模型、演化模型、螺旋模型、噴泉模型等。瀑布模型是將軟件生存周期各個(gè)活動規(guī)定為依線性順序連接的若干階段的模型，適合于軟件需求很明確的軟件項(xiàng)目。V模型是瀑布模型的一種演變模型，將測試和分析與設(shè)計(jì)關(guān)聯(lián)進(jìn)行，加強(qiáng)分析與設(shè)計(jì)的驗(yàn)證。原型模型是一種演化模型，通過快速構(gòu)建可運(yùn)行的原型系統(tǒng)，然后根據(jù)運(yùn)行過程中獲取的用戶反饋進(jìn)行改進(jìn)。演化模型特別適用于對軟件需求缺乏準(zhǔn)確認(rèn)識的情況。螺旋模型將瀑布模型和演化模型結(jié)合起來，加入了兩種模型均忽略的風(fēng)險(xiǎn)分析。 本題中項(xiàng)目組具備了所開發(fā)系統(tǒng)的相關(guān)領(lǐng)域及類似規(guī)模系統(tǒng)的開發(fā)經(jīng)驗(yàn)，即需求明確，瀑布模型最適合開發(fā)此項(xiàng)目。
04.確定模塊以及調(diào)用關(guān)系：概要設(shè)計(jì)階段
需求分析確定軟件要完成的功能及非功能性要求；概要設(shè)計(jì)將需求轉(zhuǎn)化為軟件的模塊劃分，確定模塊之間的調(diào)用關(guān)系；詳細(xì)設(shè)計(jì)將模塊進(jìn)行細(xì)化，得到詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法；編碼根據(jù)詳細(xì)設(shè)計(jì)進(jìn)行代碼的編寫，得到可以運(yùn)行的軟件，并進(jìn)行單元測試。
05.精化階段：需求分析和架構(gòu)演進(jìn)
起始階段專注于項(xiàng)目的初創(chuàng)活動。精化階段理解了最初的領(lǐng)域范圍之后，進(jìn)行需求分析和架構(gòu)演進(jìn)。構(gòu)建階段關(guān)注系統(tǒng)的構(gòu)建，產(chǎn)生實(shí)現(xiàn)模型。移交階段關(guān)注于軟件提交方面的工作，產(chǎn)生軟件增量。產(chǎn)生階段運(yùn)行軟件并監(jiān)控軟件的持續(xù)使用，提供運(yùn)行環(huán)境的支持，提交并評估缺陷報(bào)告和變更請求。
06.軟件工程基本要素：方法、工具、過程
軟件工程是一種層次化的技術(shù)，從底向上分別為質(zhì)量、過程、方法和工具。任何工程方法必須以有組織的質(zhì)量承諾為基礎(chǔ)。軟件工程的基礎(chǔ)是過程，過程是將技術(shù)結(jié)合在一起的凝聚力，使得計(jì)算機(jī)軟件能夠被合理地和及時(shí)地開發(fā)，過程定義了一組關(guān)鍵過程區(qū)域，構(gòu)成了軟件項(xiàng)目管理控制的基礎(chǔ)；方法提供了建造軟件在技術(shù)上需要“如何做”，它覆蓋了一系列的任務(wù)。方法也依賴于一些基本原則，這些原則控制了每一個(gè)技術(shù)區(qū)域 而且包含建?；顒雍推渌枋黾夹g(shù)；工具對過程和方法提供了自動或半自動的支持，如：計(jì)算機(jī)輔助軟件工程（CASE）。軟件工程的基本要素包括方法、工具和過程。
07.原型化開發(fā)：需求基經(jīng)常變更、規(guī)模不大
需求不清晰且規(guī)模不太大時(shí)采用原型化方法最合適，而數(shù)據(jù)處理領(lǐng)域的不太復(fù)雜的軟件，適于用結(jié)構(gòu)化方法進(jìn)行開發(fā)。
08.RUP
角色：“誰做”
制品表：“做什么”
活動表：“怎么做”
工作流：“什么時(shí)候做”
09.軟件項(xiàng)目計(jì)劃進(jìn)度圖
Gantt：
不能清晰的描述任務(wù)之間的依賴關(guān)系
不能清晰的確定影響進(jìn)度的關(guān)鍵任務(wù)
PERT：不能清晰的描述各個(gè)任務(wù)之間的并行關(guān)系
軟件項(xiàng)目計(jì)劃的一個(gè)重要內(nèi)容是安排進(jìn)度，常用的方法有Gantt圖和PERT圖。Gantt 圖用水平條狀圖描述，它以日歷為基準(zhǔn)描述項(xiàng)目任務(wù)，可以清楚地表示任務(wù)的持續(xù)時(shí)間和任務(wù)之間的并行，但是不能清晰地描述各個(gè)任務(wù)之間的依賴關(guān)系。PERT圖是一種網(wǎng)絡(luò)模型，描述一個(gè)項(xiàng)目的各任務(wù)之間的關(guān)系?？梢悦鞔_表達(dá)任務(wù)之間的依賴關(guān)系，即哪些任務(wù)完成后才能開始另一些任務(wù)，以及如期完成整個(gè)工程的關(guān)鍵路徑，但是不能清晰地描述各個(gè)任務(wù)之間的并行關(guān)系。
10.概要設(shè)計(jì)階段：系統(tǒng)分成若干子系統(tǒng)，建立體系
軟件設(shè)計(jì)的任務(wù)是基于需求分析的結(jié)果建立各種設(shè)計(jì)模型，給出問題的解決方案。從工程管理的角度，可以將軟件設(shè)計(jì)分為兩個(gè)階段：概要設(shè)計(jì)階段和詳細(xì)設(shè)計(jì)階段。結(jié)構(gòu)化設(shè)計(jì)方法中，概要設(shè)計(jì)階段進(jìn)行軟件體系結(jié)構(gòu)的設(shè)計(jì)、數(shù)據(jù)設(shè)計(jì)和接口設(shè)計(jì)；詳細(xì)設(shè)計(jì)階段進(jìn)行數(shù)據(jù)結(jié)構(gòu)和算法的設(shè)計(jì)。面向?qū)ο笤O(shè)計(jì)方法中，概要設(shè)計(jì)階段進(jìn)行體系結(jié)構(gòu)設(shè)計(jì)、初步的類設(shè)計(jì)/數(shù)據(jù)設(shè)計(jì)、結(jié)構(gòu)設(shè)計(jì)；詳細(xì)設(shè)計(jì)階段進(jìn)行構(gòu)件設(shè)計(jì)。 結(jié)構(gòu)化設(shè)計(jì)和面向?qū)ο笤O(shè)計(jì)是兩種不同的設(shè)計(jì)方法，結(jié)構(gòu)化設(shè)計(jì)根據(jù)系統(tǒng)的數(shù)據(jù)流圖進(jìn)行設(shè)計(jì)，模塊體現(xiàn)為函數(shù)、過程及子程序；面向?qū)ο笤O(shè)計(jì)基于面向?qū)ο蟮幕靖拍钸M(jìn)行，模塊體現(xiàn)為類、對象和構(gòu)件等。
11.需求穩(wěn)定，項(xiàng)目不大：結(jié)構(gòu)化開發(fā)
需求不清晰且規(guī)模不太大時(shí)采用原型化方法最合適，而數(shù)據(jù)處理領(lǐng)域的不太復(fù)雜的軟件，適于用結(jié)構(gòu)化方法進(jìn)行開發(fā)。
12.并列爭球法：迭代方式并行遞增實(shí)現(xiàn)產(chǎn)品
極限編程XP是激發(fā)開發(fā)人員創(chuàng)造性、使得管理負(fù)擔(dān)最小的一組技術(shù)；水晶法Crystal認(rèn)為每一個(gè)不同的項(xiàng)目都需要一套不同的策略、約定和方法論；并列爭球法（Scrum）使用迭代的方法，其中把每30天一次的迭代成為一個(gè)沖刺，并按需求的優(yōu)先級來實(shí)現(xiàn)產(chǎn)品。多個(gè)自組織和自治小組并行地遞增實(shí)現(xiàn)產(chǎn)品，并通過簡短的日常情況會議進(jìn)行協(xié)調(diào)。
13.構(gòu)建軟件系統(tǒng)：無需考慮市場前景
在對軟件開發(fā)資源進(jìn)行規(guī)劃時(shí)，為了確定構(gòu)建軟件系統(tǒng)所需的人數(shù)，需要考慮軟件系統(tǒng)的規(guī)模、系統(tǒng)的技術(shù)復(fù)雜性、項(xiàng)目計(jì)劃和開發(fā)人員的技術(shù)背景等方面，而與系統(tǒng)是否有市場前景無關(guān)。
14.風(fēng)險(xiǎn)：不一定發(fā)聲
風(fēng)險(xiǎn)是一種具有負(fù)面后果的、人們不希望發(fā)生的事件。通常認(rèn)為風(fēng)險(xiǎn)具有以下特點(diǎn)： 風(fēng)險(xiǎn)是可能發(fā)生的事件，其發(fā)生的可能性用風(fēng)險(xiǎn)概率來描述；風(fēng)險(xiǎn)是會給項(xiàng)目帶來損失的事件；可能對風(fēng)險(xiǎn)進(jìn)行干預(yù)，以期減少損失。針對每一種風(fēng)險(xiǎn)，應(yīng)弄清可能減少造成損失或避免損失的程度。對風(fēng)險(xiǎn)加以控制，采取一些有效的措施來降低風(fēng)險(xiǎn)或是消除風(fēng)險(xiǎn)。
15.基本COCOMO：靜態(tài)單變量模型、對整個(gè)軟件系統(tǒng)進(jìn)行估算
COCOMO用3個(gè)不同層次的模型來反映不同程度的復(fù)雜性，它們分別為：
基本模型（Basic Model）：是一個(gè)靜態(tài)單變量模型，它用一個(gè)以已估算出來的源代碼行數(shù)（LOC）為自變量的函數(shù)來計(jì)算軟件開發(fā)工作量。
中級模型（Intermediate Model）：則在用LOC為自變量的函數(shù)計(jì)算軟件開發(fā)工作量的基礎(chǔ)上，再用涉及產(chǎn)品、硬件、人員、項(xiàng)目等方面屬性的影響因素來調(diào)整工作量的估算。
詳細(xì)模型（Detailed Model）：包括中級COCOMO型的所有特性，但用上述各種影響因素調(diào)整工作量估算時(shí)，還要考慮對軟件工程過程中分析、設(shè)計(jì)等各步驟的影響。
16.盡早交付：小型發(fā)布
敏捷開發(fā)方法XP是一種輕量級、高效、低風(fēng)險(xiǎn)、柔性、可預(yù)測的、科學(xué)的軟件開發(fā)方法，其特性包含在12個(gè)最佳實(shí)踐中。
1.計(jì)劃游戲：快速制定計(jì)劃、隨著細(xì)節(jié)的不斷變化而完善；
2.小型發(fā)布：系統(tǒng)的設(shè)計(jì)要能夠盡可能早地交付；
3.隱喻：找到合適的比喻傳達(dá)信息；
4.簡單設(shè)計(jì)：只處理當(dāng)前的需求使設(shè)計(jì)保持簡單；
5.測試先行：先寫測試代碼再編寫程序；
6.重構(gòu)：重新審視需求和設(shè)計(jì)，重新明確地描述它們，以符合新的和現(xiàn)有的需求;
7.結(jié)隊(duì)編程；
8.集體代碼所有制；
9.持續(xù)集成：可以按日甚至按小時(shí)為客戶提供可運(yùn)行的版本；
10.每周工作40個(gè)小時(shí)；
11.現(xiàn)場客戶；
12.編碼標(biāo)準(zhǔn)。
17.專家判斷方法、啟發(fā)式方法、機(jī)器學(xué)習(xí)：總和可以得到精確的估算結(jié)果
項(xiàng)目估算是項(xiàng)目計(jì)劃和管理的一個(gè)至關(guān)重要的方面。成本超出某個(gè)限度可能導(dǎo)致客戶取消項(xiàng)目，而過低的成本估算可能會迫使開發(fā)小組投入大量的時(shí)間卻沒有相應(yīng)的經(jīng)濟(jì)回報(bào)。目前常用的項(xiàng)目估算方法有專家判斷方法，該方法受到專家經(jīng)驗(yàn)和主觀性等方面的影響；算法方法，根據(jù)某個(gè)計(jì)算模型來估算項(xiàng)目開發(fā)成本，如啟發(fā)式方法COCOMO 模型，但這些模型中的參數(shù)難以確定；機(jī)器學(xué)習(xí)方法，如根據(jù)過去的項(xiàng)目開發(fā)數(shù)據(jù)，建立分類模型，預(yù)測新項(xiàng)目的開發(fā)成本，但這類方法難以定義訓(xùn)練數(shù)據(jù)的特征以及定義數(shù)據(jù)對象之間的相似性。即使結(jié)合多種方法，上述問題仍然存在，因此并不能得到精確地估算結(jié)果。
18.無主程序員：不適合大型項(xiàng)目
大規(guī)模項(xiàng)目最不適于采用無主程序員組的開發(fā)人員組織形式，因?yàn)榇箜?xiàng)目需要主程序員來整合各模塊程序。
19.響應(yīng)速度要求：非功能要求
軟件需求是軟件系統(tǒng)必須完成的事以及必須具備的品質(zhì)。軟件需求包括功能需求、非功能需求和設(shè)計(jì)約束三個(gè)方面的內(nèi)容。功能需求是所開發(fā)的軟件必須具備什么樣的功能：非功能需求是指產(chǎn)品必須具備的屬性或品質(zhì)，如可靠性、性能、響應(yīng)時(shí)間和擴(kuò)展性等等;設(shè)計(jì)約束通常對解決方案的一些約束說明。“軟件產(chǎn)品必須能夠在3秒內(nèi)對用戶請求作出響應(yīng)”主要表述軟件的響應(yīng)時(shí)間，屬于非功能需求。
20.軟件風(fēng)險(xiǎn)特征：不確定性、損失
軟件風(fēng)險(xiǎn)一般包括不確定性和損失兩個(gè)特性，其中不確定性是指風(fēng)險(xiǎn)可能發(fā)生，也可能不發(fā)生：損失是當(dāng)風(fēng)險(xiǎn)確實(shí)發(fā)生時(shí)，會引起的不希望的后果和損失。救火和危機(jī)管理是對不適合但經(jīng)常采用的軟件風(fēng)險(xiǎn)管理策略。已知風(fēng)險(xiǎn)和未知風(fēng)險(xiǎn)是對軟件風(fēng)險(xiǎn)進(jìn)行分類的一種方式。員工和預(yù)算是在識別項(xiàng)目風(fēng)險(xiǎn)時(shí)需要識別的因素。
21.風(fēng)險(xiǎn)預(yù)測：風(fēng)險(xiǎn)發(fā)生可能性、發(fā)生后的結(jié)果
22.風(fēng)險(xiǎn)
風(fēng)險(xiǎn)分析實(shí)際上是4個(gè)不同的活動：風(fēng)險(xiǎn)識別、風(fēng)險(xiǎn)預(yù)測、風(fēng)險(xiǎn)評估和風(fēng)險(xiǎn)控制。
風(fēng)險(xiǎn)識別：是試圖系統(tǒng)化地確定對項(xiàng)目計(jì)劃（估算、進(jìn)度、資源分配）的威脅。
風(fēng)險(xiǎn)預(yù)測：又稱為風(fēng)險(xiǎn)估算，它從兩個(gè)方面評估一個(gè)風(fēng)險(xiǎn)：風(fēng)險(xiǎn)發(fā)生的可能性或概率；以及如果風(fēng)險(xiǎn)發(fā)生時(shí)所產(chǎn)生的后果。
風(fēng)險(xiǎn)評估：根據(jù)風(fēng)險(xiǎn)及其發(fā)生的概率和產(chǎn)生的影響預(yù)測是否影響 參考水平值。
風(fēng)險(xiǎn)控制：的目的是輔助項(xiàng)目組建立處理風(fēng)險(xiǎn)的策略，有效的策略應(yīng)考慮風(fēng) 險(xiǎn)避免、風(fēng)險(xiǎn)監(jiān)控、風(fēng)險(xiǎn)管理及意外事件計(jì)劃。
23.最好的風(fēng)險(xiǎn)控制策略：風(fēng)險(xiǎn)避免
風(fēng)險(xiǎn)避免即放棄或不進(jìn)行可能帶來損失的活動或工作。例如，為了避免洪水風(fēng)險(xiǎn)，可以把工廠建在地勢較高、排水方便的地方，這是一種主動的風(fēng)險(xiǎn)控制方法。風(fēng)險(xiǎn)監(jiān)控是指在決策主體的運(yùn)行過程中，對風(fēng)險(xiǎn)的發(fā)展與變化情況進(jìn)行全程監(jiān)督，并根據(jù)需要進(jìn)行應(yīng)對策略的調(diào)整。風(fēng)險(xiǎn)管理是指在一個(gè)肯定有風(fēng)險(xiǎn)的環(huán)境里把風(fēng)險(xiǎn)減至最低的管理過程。對于風(fēng)險(xiǎn)我們可以轉(zhuǎn)移，可以規(guī)避，但不能消除。
24.風(fēng)險(xiǎn)參照水準(zhǔn)：風(fēng)險(xiǎn)估評類技術(shù)
定義風(fēng)險(xiǎn)參照水準(zhǔn)是風(fēng)險(xiǎn)評估的一類技術(shù)，對于大多數(shù)軟件項(xiàng)目來說成本、速度和性能是三種典型的風(fēng)險(xiǎn)參照水準(zhǔn)。
25.風(fēng)險(xiǎn)優(yōu)先級：根據(jù)風(fēng)險(xiǎn)暴露(Risk Exposure)設(shè)定
風(fēng)險(xiǎn)是一種具有負(fù)面后果的、人們不希望發(fā)生的事件。風(fēng)險(xiǎn)管理是軟件項(xiàng)目管理的一項(xiàng)重要任務(wù)。在進(jìn)行風(fēng)險(xiǎn)管理時(shí)，根據(jù)風(fēng)險(xiǎn)的優(yōu)先級來確定風(fēng)險(xiǎn)控制策略，而優(yōu)先級是根據(jù)風(fēng)險(xiǎn)暴露來確定的。風(fēng)險(xiǎn)暴露是一種量化風(fēng)險(xiǎn)影響的指標(biāo)，等于風(fēng)險(xiǎn)影響乘以風(fēng)險(xiǎn)概率，風(fēng)險(xiǎn)影響是當(dāng)風(fēng)險(xiǎn)發(fā)生時(shí)造成的損失。風(fēng)險(xiǎn)概率是風(fēng)險(xiǎn)發(fā)生的可能性。風(fēng)險(xiǎn)控制是風(fēng)險(xiǎn)管理的一個(gè)重要活動。
26.組織團(tuán)隊(duì)：要考慮人員的工作做風(fēng)
人員管理是軟件項(xiàng)目管理的一個(gè)重要部分，在組織開發(fā)團(tuán)隊(duì)時(shí)，應(yīng)該考慮開發(fā)人員的工作能力、知識背景、工作風(fēng)格、興趣愛好等多方面的因素。每個(gè)成員的工作任務(wù)分配清楚，不應(yīng)該參與所有階段的工作。當(dāng)項(xiàng)目進(jìn)度滯后于項(xiàng)目計(jì)劃時(shí)，增加開發(fā)人員不一定可以加快開發(fā)進(jìn)度。
27.需求分析階段：不包括軟件體系結(jié)構(gòu)圖的輸出
結(jié)構(gòu)化分析模型包括數(shù)據(jù)流圖、實(shí)體聯(lián)系圖、狀態(tài)遷移圖和數(shù)據(jù)字典，因此這些模型是需求分析階段的輸出。而確定軟件體系結(jié)構(gòu)是在軟件設(shè)計(jì)階段進(jìn)行的。
28.COCOMO II：包含了三個(gè)階段性的模型
存在多種軟件項(xiàng)目管理的成本估算方法。其中專家估算方法主要依賴于專家的背景和經(jīng)驗(yàn)，具有較大的主觀性。Wolverton模型基于一個(gè)成本矩陣，定義不同的軟件類型（如控制、輸入/輸出等）和難易（容易和困難）的成本，基于此計(jì)算軟件開發(fā)的成本。COCOMO模型將規(guī)模視為成本的主要因素，考慮多個(gè)成本驅(qū)動因子。在后來的版本COCOMO II中，還考慮了軟件開發(fā)的不同階段，包含三個(gè)階段性模型，即應(yīng)用組裝模型、早期設(shè)計(jì)階段模型和體系結(jié)構(gòu)階段模型。
29.可預(yù)測的風(fēng)險(xiǎn)：不一定能避免發(fā)生
一般認(rèn)為軟件風(fēng)險(xiǎn)包含兩個(gè)特性：不確定性和損失，不確定性即指風(fēng)險(xiǎn)可能發(fā)生也可能不發(fā)生。評估風(fēng)險(xiǎn)的影響，如果風(fēng)險(xiǎn)真的發(fā)生，有3個(gè)因素可能會影響風(fēng)險(xiǎn)所產(chǎn)生的后果，即風(fēng)險(xiǎn)的本質(zhì)、范圍和時(shí)間。如果風(fēng)險(xiǎn)可以預(yù)測，可以避免其發(fā)生，有些風(fēng)險(xiǎn)可以預(yù)測但無法避免。風(fēng)險(xiǎn)控制的目的是輔助項(xiàng)目組建立處理風(fēng)險(xiǎn)的策略。
30.COCOMO II：對象點(diǎn)、功能點(diǎn)、源代碼行
COCOMOII模型也需要使用規(guī)模估算信息，在模型層次結(jié)構(gòu)中有3種不同規(guī)模估算選擇，即：對象點(diǎn)、功能點(diǎn)和代碼行。
31.IO軟件：隱藏實(shí)現(xiàn)細(xì)節(jié)、提供邏輯接口
I/O軟件隱藏了I/O操作實(shí)現(xiàn)的細(xì)節(jié)。I/O軟件向用戶提供的是邏輯接口。I/O軟件將硬件與較高層次的軟件隔離開來，而最高層軟件向應(yīng)用提供一個(gè)友好的、清晰且統(tǒng)一的接口，方便用戶使用。
32.重構(gòu)(Refactoring)不屬于：敏捷開發(fā)Scrum方法步驟
Product Backlog 產(chǎn)品待辦事項(xiàng)清單；Refactoring 重構(gòu)，不屬于scrum的步驟；Sprint Backlog，Sprint待辦事項(xiàng)清單；Sprint，沖刺迭代。
33.CMMI：1級是初級
CMM（Capability Maturity Model）是能力成熟度模型的縮寫，CMM是國際公認(rèn)的對軟件公司進(jìn)行成熟度等級認(rèn)證的重要標(biāo)準(zhǔn)。CMM共分五級。在每一級中，定義了達(dá)到該級過程管理水平所應(yīng)解決的關(guān)鍵問題和關(guān)鍵過程。每一較低級別是達(dá)到較高級別的基礎(chǔ)。其中五級是最高級，即優(yōu)化級，達(dá)到該級的軟件公司過程可自發(fā)地不斷改進(jìn)，防止同類問題二次出現(xiàn)；四級稱為已管理級，達(dá)到該級的軟件公司已實(shí)現(xiàn)過程的定量化；三級為已定義級，即過程實(shí)現(xiàn)標(biāo)準(zhǔn)化；二級為可重復(fù)級，達(dá)到該級的軟件公司過程已制度化，有紀(jì)律，可重復(fù)；一級為初始級，過程無序，進(jìn)度、預(yù)算、功能和質(zhì)量等方面不可預(yù)測。
34.易使用性子特征：不包括易分析性
易用性的自特性包括易理解性、易學(xué)性、易操作性，易分析性屬于可維護(hù)性的子特性。
35.CMM第3級：使用標(biāo)準(zhǔn)開發(fā)過程構(gòu)建系統(tǒng)
建立基本的項(xiàng)目管理和實(shí)踐來跟蹤項(xiàng)目費(fèi)用、進(jìn)度和功能特性為可重復(fù)級的核心；使用標(biāo)準(zhǔn)開發(fā)過程（或方法論）構(gòu)建（或集成）系統(tǒng)為已定義級的核心；管理層尋求更主動地應(yīng)對系統(tǒng)的開發(fā)問題為已管理級的核心；連續(xù)地監(jiān)督和改進(jìn)標(biāo)準(zhǔn)化的系統(tǒng)開發(fā)過程為優(yōu)先級的核心。
36.CMM第4級：對軟件過程和產(chǎn)品有定量理解和控制
在CMM的不同等級有不同的核心。在可重復(fù)級，建立了基本的項(xiàng)目管理過程和實(shí)踐來跟蹤項(xiàng)目費(fèi)用、進(jìn)度和功能特性。在已定義級，所有項(xiàng)目都采用根據(jù)實(shí)際情況修改后得到的標(biāo)準(zhǔn)軟件過程來開發(fā)和維護(hù)軟件。在已管理級，收集對軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量，對軟件過程和產(chǎn)品都有定量的理解與控制。在優(yōu)化級，過程的量化反饋和先進(jìn)的新思想、新技術(shù)促使過程不斷改進(jìn)。
37.信息庫：不屬于配置數(shù)據(jù)庫
軟件變更控制是變更管理的重要內(nèi)容，要有效進(jìn)行變更控制，需要借助配置數(shù)據(jù)庫和基線的概念。配置數(shù)據(jù)庫一般包括開發(fā)庫、受控庫和產(chǎn)品庫。
38.有效捕獲系統(tǒng)需求：原型模型
軟件過程是軟件生命周期中的一系列相關(guān)活動，即用于開發(fā)和維護(hù)軟件及相關(guān)產(chǎn)品的一系列活動。軟件過程模型可以幫助開發(fā)團(tuán)隊(duì)理解開發(fā)過程，形成對開發(fā)中的活動、資源和約束的共同理解，可以根據(jù)具體情況對一個(gè)過程進(jìn)行裁剪等。瀑布模型從一種非常高層的角度描述了軟件開發(fā)過程中進(jìn)行的活動，并且提出了要求開發(fā)人員經(jīng)過的事件序列。該模型適用于項(xiàng)目開始時(shí)需求已確定的情況。V模型是瀑布模型的變種，它說明測試活動是如何與分析和設(shè)計(jì)相聯(lián)系的。原型模型允許開發(fā)人員快速地構(gòu)造整個(gè)系統(tǒng)或系統(tǒng)的一部分以理解或澄清問題。原型的用途是獲知用戶的真正需求，因此原型模型可以有效地引發(fā)系統(tǒng)需求。螺旋模型把開發(fā)活動和風(fēng)險(xiǎn)管理結(jié)合起來，以將風(fēng)險(xiǎn)減到最小并控制風(fēng)險(xiǎn)。
39.噴泉模型：不存在明顯邊界
噴泉模型是典型的面向?qū)ο笊芷谀Ｐ?，是一種以用戶需求為動力，以對象作為驅(qū)動的模型。該模型克服了瀑布模型不支持軟件重用和多項(xiàng)開發(fā)活動集成的局限性?！皣娙?一詞本身體現(xiàn)了迭代和無間隙特性。迭代意味著模型中的開發(fā)活動常常需要重復(fù)多次，在迭代過程中不斷地完善軟件系統(tǒng)；無間隙是指在開發(fā)活動之間不存在明顯的邊界。
40.增量模型：快速構(gòu)建可運(yùn)行產(chǎn)品
增量模型是一種非整體開發(fā)的模型，該模型具有較大的靈活性，適合于軟件需求不明確的一種模型。使用該模型開發(fā)產(chǎn)品，一般是盡快構(gòu)造出可運(yùn)行的產(chǎn)品，然后在該產(chǎn)品的基礎(chǔ)上再增加需要的新的構(gòu)建，使產(chǎn)品更趨于完善。
41.了解相關(guān)領(lǐng)域：瀑布開發(fā)模型
項(xiàng)目規(guī)模大、開發(fā)小組對項(xiàng)目需求理解并了解相關(guān)領(lǐng)域，因此可以采用瀑布開發(fā)模型。演化模式適用于對軟件需求缺乏準(zhǔn)確認(rèn)識的情況。螺旋模型在開發(fā)過程中加入風(fēng)險(xiǎn)分析。噴泉模型適合于面向?qū)ο蟮拈_發(fā)方法。
42.缺乏全面認(rèn)識：最不適合瀑布模型
瀑布模型是一種經(jīng)典的開發(fā)模型，開發(fā)過程是通過設(shè)計(jì)一系列階段順序展開的，從系統(tǒng)需求分析開始直到產(chǎn)品發(fā)布和維護(hù)，每個(gè)階段都會產(chǎn)生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現(xiàn)了問題，那么最好 “返回”上一個(gè)階段并進(jìn)行適當(dāng)?shù)男薷?，?xiàng)目開發(fā)進(jìn)程從一個(gè)階段“流動”到下一個(gè)階段，這也是瀑布模型名稱的由來。瀑布模型的突出缺點(diǎn)是不適應(yīng)用戶需求的變化。
43.UP
UP （統(tǒng)一過程）模型是一種以用例和風(fēng)險(xiǎn)為驅(qū)動、以架構(gòu)為中心、迭代并且增量的開發(fā)過程，由UML方法和工具支持。
UP過程定義了五個(gè)階段，起始階段、精化階段、構(gòu)建階段、移交階段和產(chǎn)生階段。
開發(fā)過程中有多次迭代，每次迭代都包含計(jì)劃、分析、 設(shè)計(jì)、構(gòu)造、集成和測試，以及內(nèi)部和外部發(fā)布。
每個(gè)迭代有五個(gè)核心工作流，捕獲系統(tǒng)應(yīng)該做什么的需求工作流、精化和結(jié)構(gòu)化需求的分析工作流、在系統(tǒng)結(jié)構(gòu)內(nèi)實(shí)現(xiàn)需求的設(shè)計(jì)工作流、構(gòu)造軟件的實(shí)現(xiàn)工作流和驗(yàn)證是否如期望那樣工作的測試工作流。
44.技術(shù)高、風(fēng)險(xiǎn)多、項(xiàng)目大：適合螺旋模型
瀑布模型將軟件生存周期各個(gè)活動規(guī)定為線性順序連接的若干階段的模型，規(guī)定了由前至后，相互銜接的固定次序，如同瀑布流水，逐級下落。這種方法是一種理想的開發(fā)模式，缺乏靈活性，特別是無法解決軟件需求不明確或不準(zhǔn)確的問題。 原型模型從初始的原型逐步演化成最終軟件產(chǎn)品，特別適用于對軟件需求缺乏準(zhǔn)確認(rèn)識的情況。 增量開發(fā)是把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計(jì)、編碼、集成和測試，可以在增量開發(fā)過程中逐步理解需求。 螺旋將瀑布模型與快速原型模型結(jié)合起來，并且加入兩種模型均忽略了的風(fēng)險(xiǎn)分析，適用于復(fù)雜的大型軟件。
45.超大規(guī)模軟件：最不適合原型模型
瀑布模型將開發(fā)階段描述為從一個(gè)階段瀑布般地轉(zhuǎn)換到另一個(gè)階段的過程。 原型模型中，開發(fā)人員快速地構(gòu)造整個(gè)系統(tǒng)或者系統(tǒng)的一部分以理解或澄清問題。螺旋模型將開發(fā)活動和風(fēng)險(xiǎn)管理結(jié)合起來，以減小風(fēng)險(xiǎn)。 噴泉模型開發(fā)過程模型以用戶需求為動力，以對象為驅(qū)動，適合于面向?qū)ο蟮拈_發(fā)方法。 在這幾種開發(fā)過程模型中，原型模型不適宜大規(guī)模軟件的開發(fā)。
