一、術語（29道）每題4分
-
軟件生存週期
軟件生存週期（software life cycle）又稱爲軟件生命期，生存期。是指從形成開發軟件概念起，所開發的軟件使用以後，直到失去使用價值消亡爲止的整個過程。一般來說，整個生存週期包括計劃（定義）、開發、運行（維護）三個時期，每一個時期又劃分爲若干階段。每個階段有明確的任務，這樣使規模大、結構複雜和管理複雜的軟件開發變得容易控制和管理。
SDLC的六個階段：1. 定義及規劃2.需求分析3. 軟件設計4.程序編碼5.軟件測試6.運行維護 -
項目
項目是指一系列獨特的、複雜的並相互關聯的活動，這些活動有着一個明確的目標或目的，必須在特定的時間、預算、資源限定內，依據規範完成。項目是爲創造獨特的產品、服務或成果而進行的臨時性工作。
項目參數包括項目範圍、質量、成本、時間、資源。 -
里程碑
在制定項目進度計劃時，在進度時間表上設立一些重要的時間檢查點，這樣一來，就可以在項目執行過程中利用這些重要的時間檢查點來對項目的進程進行檢查和控制。這些重要的時間檢查點被稱作項目的里程碑（Milestone）。 -
軟件度量
軟件度量是對軟件開發項目、過程及其產品進行數據定義、收集以及分析的持續性定量化過程，目的在於對此加以理解、預測、評估、控制和改善。 -
功能點分析
功能點分析方法是最重要也是最有效的軟件測量規模方法，它可以在項目早期就對軟件項目進行測量，並在開發過程中不斷地更新數據，從而實現一種持續一致的管理。從應用方面看，全球已經有成千上萬個項目採用了功能點分析方法。從研究方面來看，功能點分析方法也已成爲很多其他新型測量方法的基礎。
功能點分析是項目工作量估算的一種常用方法，可用7個步驟概括：1.確定功能點計算的類型；2.確定計算範圍和應用程序邊界；3.確定所有數據功能及其複雜性；4.確定所有事務功能及其複雜性；5.得出未調整功能點計數；6得出基於系統基本特徵的值調整因子；7.計算已調整功能點計數。 -
工作分解結構（WBS）
WBS是項目管理重要的專業術語之一。WBS的基本定義 ：以可交付成果爲導向對項目要素進行的分組，它歸納和定義了項目的整個工作範圍每下降一層代表對項目工作的更詳細定義。無論在項目管理實踐中，還是在PMP，IPMP考試中，工作分解結構（WBS）都是最重要的內容之一。WBS總是處於計劃過程的中心，也是制定進度計劃、資源需求、成本預算、風險管理計劃和採購計劃等的重要基礎。WBS同時也是控制項目變更的重要基礎。 -
軟件質量
軟件質量就是“軟件與明確的和隱含的定義的需求相一致的程度”。具體地說，軟件質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發標準、以及所有專業開發的軟件都應具有的和隱含特徵相一致的程度。 影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量。可劃分爲三組，分別反應用戶在使用軟件產品時的三種觀點。正確性、健壯性、效率、完整性、可用性、風險（產品運行）；可理解性、可維修性、靈活性、可測試性（產品修改）；可移植性、可再用性、互運行性（產品轉移）。 -
RMMM 計劃（Risk Mitigation, Monitoring and Management Plan）
軟件項目風險管理是軟件項目管理的重要內容。在進行軟件項目風險管理時，要辯識風險，評估它們出現的概率及產生的影響，然後建立一個規劃來管理風險。風險管理的主要目標是預防風險。
軟件項目風險是指在軟件開發過程中遇到的預算和進度等方面的問題以及這些問題對軟件項目的影響。軟件項目風險會影響項目計劃的實現，如果項目風險變成現實，就有可能影響項目的進度，增加項目的成本，甚至使軟件項目不能實現。如果對項目進行風險管理，就可以最大限度的減少風險的發生。 -
COCOMO 模型
結構性成本模型。它是由巴里·勃姆（Barry Boehm）提出的一種軟件成本估算方法。這種模型使用一種基本的迴歸分析公式，本質上說是一種參數化的項目估算方法，參數建模是把項目的某些特徵作爲參數，通過建立一個數字模型預測項目成本（類似於居住面積作爲參數計算的整體的住房成本）。 -
項目計劃評審技術
計劃評審技術就是工程項目當作一種系統，用網絡圖或者表格或者矩陣來表示各項具體工作的先後順序和相互關係，以時間爲中心，找出從開工到完工所需要時間的最長路線，並圍繞關鍵路線對系統進行統籌規劃，合理安排以及對各項工作的完成進度進行嚴密的控制，以達到用最少的時間和資源消耗來完成系統預定目標的一種計劃與控制方法。 -
軟件質量模型
一個軟件的質量往往涉及到許多不同的質量屬性,不同類型的軟件所關注的質量屬性也不盡相同。因此, 爲了更好地理解、預測和評價軟件和信息系統的質量, 人們建立了各種質量模型, 在軟件生命週期的不同階段對軟件質量進行評測。常用的通用軟件質量模型主要包括層次模型和關係模型, 它們在當前的軟件開發中起到了一定的積極作用。 -
基於時間的缺陷到達模式
產品的缺陷密度、或者測試階段的缺陷率是一個概括性指標，缺陷到達模式可以提供更多的過程信息，有時即使得到的整體缺陷率是一樣的，但其質量差異可能較大，原因就是缺陷到達的模式不一樣。越多的缺陷到達越早，則測試過程質量就越好。無論是從測試進展的觀點，還是從用戶重新發現(customer rediscoveries)的觀點來看，缺陷的過程跟蹤是非常重要的，開發週期裏大量的嚴重缺陷將有可能阻止測試的進展，也必然直接影響軟件產品的質量和性能。定性的分析比較容易，測試團隊越成熟，峯值到達得越早，有時可以在第一週末或第二週就達到峯值。這個峯值的數值取決於代碼質量、測試用例的設計質量和測試執行的策略、水平等，多數情況下，可以根據基線（或歷史數據）推得。從一個峯值達到一個低而穩定的水平，需要長得多的時間，至少是達到峯值所用的時間的4-5倍。這個時間取決於峯值、缺陷移除效率等等。
在測試階段初期，缺陷率增長很快。在達到峯值後，就隨時間以較慢的速率下降，降低到最低點——零點。 -
軟件過程
軟件過程爲一個爲建造高質量軟件所需完成的任務的框架，即形成軟件產品的一系列步驟，包括中間產品、資源、角色及過程中採取的方法、工具等範疇。
（課件）
人們在開發和維護軟件機器相關產品時所涉及的各種活動、方法、實踐和改革等。其中軟件相關產品包括軟件項目計劃、設計文檔、程序代碼、測試用例和用戶手冊等。 -
軟件基本過程
軟件獲取、供應、開發、運行和維護的過程，包括需求分析、軟件設計、編碼等過程。 -
軟件支持過程
包括文檔編制過程、配置管理過程、質量保證過程、驗證和確認過程（測試過程）、評審過程等。 -
軟件組織過程
對軟件主要過程和支持過程的組織保證過程，包括管理過程、基礎設施過程、改進過程和培訓過程。 -
過程框架
通過在軟件過程環境中定義軟件過程架構、軟件過程改進規劃圖、軟件過程評估、軟件過程改進計劃四項框架活動來建立適用於目標軟件項目的基本概念結構。 -
軟件能力成熟度模型
軟件能力成熟度模型是一種對軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述形成的標準。CMM的核心是把軟件開發視爲一個過程，並根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化、標準化、使企業能夠更好地實現商業目標。 -
統一過程
統一過程主要分五個階段：開啓階段(inception)，細化階段(elaboration)，構建階段(construction)，移交階段(transition)，生產(production)。Rational Unified Process 是 Rational 公司開發和維護的過程產品。Rational Unified Process 是軟件工程的過程。它提供了在開發組織中分派任務和責任的紀律化方法。它的目標是在可預見的日程和預算前提下，確保滿足最終用戶需求的高質量產品。 -
過程模式
一系列用來面向對象軟件的通用技術、行爲或各種任務、過程模式的一個重要特性在於，它只描述了一個軟件開發人員應該做什麼，而沒有確切地說明應該做哪些細節。當過程模式能夠被有組織的應用在一起時，它們就可以被用來爲軟件開發改進機構生成軟件過程。因爲過程模式並沒有指定如何完成一個給定的工作，它們能夠成爲可複用的積木。軟件開發人員可以據此來定製一個滿足軟件開發機構的特定需求的軟件過程。 -
個體軟件過程
PSP個人軟件過程 (Personal Software Process，PSP) 是一種可用於控制、管理和改進個人工作方式的自我持續改進過程，是一個包括軟件開發表格、指南和規程的結構化框架。PSP與具體的技術（程序設計語言、工具或者設計方法）相對獨立，其原則能夠應用到幾乎任何的軟件工程任務之中。PSP能夠說明個體軟件過程的原則； 幫助軟件工程師作出準確的計劃；確定軟件工程師爲改善產品質量要採取的步驟；建立度量個體軟件過程改善的基準；確定過程的改變對軟件工程師能力的影響。 -
團隊軟件過程 TSP
團隊軟件過程是爲開發軟件產品的開發團隊提供指導，TSP的早期實踐側重於幫助開發團隊改善其質量和生產率，以使其更好的滿足成本及進度的目標。TSP被設計爲滿足2~20人規模的開發團隊，大型的多團隊過程的TSP被設計爲大約最多爲150人左右的規模。
團隊軟件過程(TSP)加上PSP幫助高績效的工程師在一個團隊中工作，來開發有質量保證的軟件產品，生產安全的軟件產品，改進組織中的過程管理。通過TSP，一個組織能夠建立起自我管理的團隊來計劃追蹤他們的工作、建立目標，並擁有自己的過程和計劃。這些團隊可以是純粹的軟件開發團隊，也可以是集成產品的團隊，規模可以從3到20個工程師不等。TSP團隊在廣泛領域裏可能運用XP, RUP或其它方法。TSP使具備PSP的工程人員組成的團隊能夠學習並取得成功。如果你的組織運用TSP，它會幫助您的組織建立一套成熟規範的工程實踐，確保安全可靠的軟件。 -
過程規範
過程規範就是對輸入/輸出和活動所構成的過程進行明文規定或約定俗成的標準。軟件過程規範是軟件開發組織行動的準則與指南，可以依據上述各類過程的特點而建立相應的規範，如軟件基本過程規範、軟件支持過程規範和軟件組織過程規範。 -
過程模型
所謂軟件過程模型就是一種開發策略，這種策略針對軟件工程的各個階段提供了一套範形，使工程的進展達到預期的目的。對一個軟件的開發無論其大小，我們都需要選擇一個合適的軟件過程模型，這種選擇基於項目和應用的性質、採用的方法、需要的控制，以及要交付的產品的特點。
常見的模型包括瀑布模型、螺旋模型、增量模型、迭代模型、V模型等。 -
配置管理
配置管理（Configuration Management，CM）是通過技術或行政手段對軟件產品及其開發過程和生命週期進行控制、規範的一系列措施。配置管理的目標是記錄軟件產品的演化過程，確保軟件開發者在軟件生命週期中各個階段都能得到精確的產品配置。 -
配置項
配置項指納入配置管理範疇的所有項目。凡是納入配置管理範疇的工作成果都是配置項（CI）；一個純軟件的CIs通常也稱爲軟件配置（CSCIs）。配置項主要有兩大類：屬於產品組成部分的工作成果；項目管理和機構支撐過程產生的文檔。
每個配置項的主要屬性有：名稱、標識符文件狀態、版本、作者、日期等。 -
基線
基線是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨後的工作基於此標準，並且只有經過授權後才能變更這個標準。建立一個初始基線後，以後每次對其進行的變更都將記錄爲一個差值，直到建成下一個基線。 -
預防性維護
預防性維護是軟件產品交付後進行的修改，以在軟件產品中的潛在錯誤成爲實際錯誤前，檢測和更正它們。 -
適應性維護
計算機領域的各個方面發展變化十分迅速，經常會出現新的系統或新的版本，外部設備及其他系統原件經常在改變，而應用軟件的使用時間，往往比原先的系統環境使用時間更爲長久，因此，常需對軟件加以改造，使之適應於新的環境。爲使軟件產品在新的環境下仍能使用而進行的維護，稱爲適應性維護。
二、簡答題（15道） 每題10分
-
試給出在 SEI 的 CMMI 模型中採用過程評估和改進方法的兩個優點和兩個缺點。
-
考慮你所在機構中所用的軟件過程類型。使用 SEI 模型找出了多少個關鍵過程域？根據該模型，你所在機構的過程成熟度等級如何劃定？
-
若過程改進中包括度量人在過程中的工作，並對過程進行徹底的變更，這樣的項目是否是不人道的？對過程改進會發生哪些牴觸行爲？
-
給出 SEI 的 CMMI 不能適用的兩個領域，並說明理由。
-
如何將現有的軟件開發向敏捷開發方法轉換？期間會遇到哪些困難，如何解決？
-
分析比較 CMMI、ISO15504 和 6sigma 之間的共同點和區別。
-
軟件過程爲什麼必須進行改進？
（軟工課件）
凡是活動，都存在過程；凡是過程，都存在改進；凡是改進，都沒有終點。軟件過程改進的必要性主要表現在以下幾點：
經過一段時間後，過程的性能區域降低；
客戶有越來愈高的需求；
組織的過程是逐步成熟的；
組織的目標可能是變化的；
組織的環境是不斷變化的；
競爭對手在改進。 -
軟件工程中引入軟件過程的作用和意義是什麼？
（軟工複習題）
軟件過程是軟件生存期中的一系列相關軟件工程活動的集合。每個軟件過程是由一組工作任務、項目里程碑、軟件工程產品和交付物、質量保證點等組成。
軟件過程是爲了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。軟件過程的優劣決定了軟件質量的高低，好的過程是高效高質量的前提。 -
軟件過程改進中如何管理變革？
（課件）
夥伴策略：依賴於個人之間的關係；利用研討會、午餐會和活動來宣佈和討論需要改變的事情以及如何改變。
政策策略：試圖通過影響官方和非官方的領導人，使強大的組織結構發生變革‘尋找和說服那些最受尊敬、有衆多支持者的人。
經濟策略：相信金錢具有最好的說服力；基於假設-人們的原動力的經濟刺激。
對抗策略：基於假設-如果能夠喚起並調動起人們對當前問題的不滿和憤怒，他們會願意改變；更多地依賴於策略家的說服力，是人們感到現存的問題，但不提倡暴力。
學術策略：假設如果你提供給人們足夠的信息和正確的事實，他們會接受變革；通常產生僱主、專家和諮詢的委員會的研究報告。
工程策略：假設工作性質發生變化，許多人員不得不改變；對組織結構方面問題的強調，導致對環境很敏感。
軍事策略：依賴於嚴酷的武力或無知；時常被軍隊、警察、學生政治壓力集團、政黨所用重點是學習在鬥爭中使用武器；需要力量和敏捷，遵守紀律將受到獎勵。 -
軟件過程改進的框架的構成是什麼？每個構成部分的作用是什麼？
（課件）
1） 軟件過程改進規劃圖
作用：劃分出過程改進中不同的階段，並指出在每個階段應具備什麼樣的特點和屬性。
2） 軟件過程評估
作用：對一個組織的軟件過程進行評估與檢查。通過評估可以幫助組織對當前的軟件過程環境與基礎有一個正確的認識。扮演了一個改進活動計劃的催化劑的角色。
3） 軟件過程改進計劃
作用：根據評估所發現的問題，有針對性的制定過程改進方案。 -
描述在軟件設計過程中的主要活動以及這些活動的輸出。使用一個實體-‐關係圖（E-‐R 圖），說明在這些活動輸出之間可能存在的關係。
-
論述度量在軟件過程改進中作用。
-
什麼叫集成化過程改進？它的意義是什麼？
-
制定軟件過程改進計劃的流程是什麼？解釋其中的主要活動的作用和目的？
-
簡述 CMMI-‐DEV V1.3 中每一成熟度等級所包含的過程域。
（課件）
成熟度等級2（7個）：需求管理、項目計劃、項目監督和控制、供應合同管理、度量和分析、過程和產品質量管理、配置管理
成熟度等級3（11個）：需求開發、技術解決方案、產品集成、驗證、確認、組織級過程焦點、組織級過程定義、組織級培訓、集成化項目管理、風險管理、決策分析和解決方案
成熟度等級4（2個）：組織級過程性能、項目定量管理
成熟度等級5（2個）：組織級改革和實施、因果分析和解決方案
三、論述題（7道）每題20分
-
在什麼情況下產品質量可能決定於開發團隊的質量？舉例說明什麼類型的軟件產品特別依賴於個人的天賦和能力。
-
ISO 9001:2008 標準中的 PDCA 循環，又叫戴明環，是美國質量管理專家休哈特博士首先提出的，由戴明採納、宣傳，獲得普及，從而也被稱爲 “戴明環” 。它是全面質量管理所應遵循的科學程序。論述它在評估軟件項目質量管理中的作用和意義。
-
結合 CMMI 的實施，論述軟件過程改進過程中主要階段的作用。
-
複用的關鍵障礙之一是使軟件工程師考慮利用現有的構件，而不是重新開發新構件，請建議 3 到 4 種軟件組織可以用來激勵軟件工程師進行復用的方式。爲了支持複用，應該採用什麼技術？
-
論企業軟件過程改進的實施。請圍繞 “企業軟件過程改進的實施” 論題，依次從以下四個方面進行論述：
（1）敘述軟件過程改進實施的主要活動。
（2）概要敘述你參與實施的企業軟件過程改進項目以及你所擔任的主要工作。
（3）論述該企業實施軟件過程改進項目中如何根據企業的實際情況採用模型標準以及實施的主要方法和步驟。
（4）具體闡述該企業在實施軟件過程改進的活動中所發現並解決的主要問題和效果。 -
在當今 “3C” 的環境下，持續的改進是企業生存發展的永恆主題，其運用的工具不是單一的。某企業擬針對“某項服務顧客投訴率高”進行改進，在不同的階段可採用哪些工具。
-
根據下圖，分析說明 CMMI-‐DEV V1.3 中，五個工程類過程域之間的互動關係。
-
如何將現有的軟件開發向敏捷開發方法轉換？期間會遇到哪些困難，如何解決？
-
總結本企業的基本過程模型。
-
本單位是否需要引入新的軟件開發方法？分析原因並給出措施。
-
軟件生存期與軟件項目的生命期有什麼區別？
-
你所在單位或項目組進行了哪些度量活動？你認爲有需要改進的地方嗎？
-
當前企業的業務都是在全球化、快速變化的環境中運營，傳統的軟件開發過程無法適應由此產生的快速軟件需求。20 世紀 90 年代後期，一些軟件開發人員在 “Agile Alliance 2001” 中系統地闡述了敏捷開發的原則，試圖強調靈活性在快速且有效地生產軟件中所發揮的作用。目前衆多的軟件生產企事業已經在實際的軟件開發過程中接納並實踐了敏捷開發方法中的基本原則。
問題 1：敏捷開發有許多典型方法，包括極限編程（eXtreme Programming）、Scrum、Crystal、DSDM 等。請問這些方法共同的基本原則是什麼？
問題 2：敏捷開發的支持者往往誇大該方法的優點，但是在實踐中，敏捷方法的基本原則有時確實很難實施。請用 200 字以內的文字說明敏捷方法中哪些原則在實踐中難以實施。
問題 3：敏捷開發方法中最有名的極限編程。請說明極限中的結對編程（Pair Programming）的概念。
問題 4：敏捷開發方法在具體實踐過程中，往往需要開發環境或工具支持，一般稱爲快速應用開發技術和可視化開發技術。請用 150 字以以內的文字說明快速應用開發技術所包含的工具有哪些，並簡要說明可視化開發技術的基本概念和技術原理。