能力成熟模型與軟件工程模型

能力成熟度模型（CMM)將軟件能力成熟度自低到高依次劃分為5級。目前， 達到CMM第3級（已定義級）是許多組織努力的目標，該級的核心是 B 。
A.建立基本的項目管理和實踐來跟蹤項目費用、進度和功能特性
B.使用標準開發過程（或方法論）構建（或集成）系統
C.管理層尋求更主動地應對系統的開發問題
D.連續地監督和改進標準化的系統開發過程

軟件能力成熟度模型（CMM)的第4級（已管理級）的核心是 C 。
A.建立基本的項目管理和實踐來跟蹤項目費用、進度和功能特性
B.組織具有標準軟件過程
C.對軟件過程和產品都有定量的理解和控制
D.先進的新思想和新技術促進過程不斷改進

能力成熟度集成模型CMMI是CMM模型的最新版本，它有連續式和階段式兩種表示方式。基于連續式表示的CMMI共有6個（0?5)能力等級，每個能力等級對應到一個一般目標以及一組一般執行方法和特定方法，其中能力等級 C 主要關注過程的組織標準化和部署。
A.1 B.2 C.3 D.4

以下關于過程改進的敘述中，錯誤的是 B 。
A.過程能力成熟度模型基于這樣的理念：改進過程將改進產品，尤其是軟件產品
B.軟件過程改進框架包括評估、計劃、改進和監控4個部分
C.軟件過程改進不是一次性的，需要反復進行
D.在評估后要把發現的問題轉化為軟件過程改進計劃

以下關于軟件系統文檔的敘述中，錯誤的是 C 。
A.軟件系統文檔既包括有一定格式要求的規范文檔，又包括系統建設過程中的各種來往文件、會議紀要、會計單據等資料形成的不規范文檔
B.軟件系統文檔可以提高軟件開發的可見度
C.軟件系統文檔不能提高軟件開發效率
D.軟件系統文檔便于用戶理解軟件的功能、性能等各項指標

為了有效地捕獲系統需求，應采用 C .
A.瀑布模型 B.V模型 C.原型模型 D.螺旋模型

關于過程改進，以下敘述中不正確的是 D 。
A.軟件質量依賴于軟件開發過程的質量，其中個人因素占主導作用
B.要使過程改進有效，需要制定過程改進目標
C.要使過程改進有效，需要進行培訓
D.CMMI成熟度模型是一種過程改進模型，僅支持階段性過程改進而不支持連續性過程改進

以下關于噴泉模型的敘述中，不正確的是 D 。
A.噴泉模型是以對象作為驅動的模型，適合于面向對象的開發方法
B.噴泉模型克服了瀑布模型不支持軟件重用和多項開發活動集成的局限性
C.模型中的開發活動常常需要重復多次，在迭代過程中不斷地完善軟件系統
D.各開發活動（如分析、設計和編碼）之間存在明顯的邊界試題

若全面采用新技術開發一個大學記賬系統，以替換原有的系統，則宜選擇采用 A 進行開發。
A.瀑布模型 B.演化模型 C.螺旋模型 D.原型模型

軟件開發的增量模型 B 。
A.最適用于需求被清晰定義的情況
B.是一種能夠快速構造可運行產品的好方法
C.最適合于大規模團隊開發的項目
D.是一種不適用于商業產品的創新模型 試題

假設某軟件公司與客戶簽訂合同開發一個軟件系統，系統的功能有較清晰的定義， 且客戶對交付時間有嚴格要求，則該系統的開發最適宜采用 A 。
A.瀑布模型 B.原型模型 C.V模型 D.螺旋模型

某開發小組欲開發一個規模較大、需求較明確的項目。開發小組對項目領域熟悉且該項目與小組開發過的某一項目相似，則適宜采用 A 開發過程模型。
A.瀑布 B.演化 C.螺旋 D.噴泉

系統工程

c是性能需求

可行性分析

某公司因業務需要，準備建立電子商務網站。
建立電子商務網站之前，應對建立電子商務網站的可行性進行分析，可行性分析的四個主要方面是什么？

可行性包括以下四個方面：
1．運行可行性
運行可行性是對方案在組織中的合適程度的度量也是人們對該系統的感覺的度量
2．技術可行性
技術可行性主要涉及三個問題：建議的技術或方案在現有技術水平下是否可以實現企業目前擁有所需的技術嗎企業擁有所需的技術專家嗎
3．經濟可行性
從經濟上考慮包括對項目所需費用的預算和對項目效益的估算這是非常重要的如果忽略了就會造成巨大的損失
4．社會可行性
要考慮各種社會因素才能確定項目是否可行由于電子商務應用系統是在社會環境中工作的除了技術和經濟等因素之外還有許多社會因素對于項目的開展起著制約的作用與項目有直接關系的人處于變動中的企業的管理制度和工作人員的文化水平等都必須作為社會和人的因素考慮在內

需求工程

乘客應當能夠隨時打印自己已經辦好登機手續的所有航段的登機牌，如果乘客信息沒有指定座位偏好，機票預訂系統就應當為它分配。( 功能需求 )

機票預定系統在一個月內發生故障的次數低于三次，系統中存儲的數據應該避免發生缺失。(可靠性需求 )

機票預定系統在處理一個業務請求平均響應時間為100ms，系統支持的QPS（Query Per Second，每秒處理請求數）在500以上。( 性能需求 )

因乘客身份認證未通過導致機票預定失敗時，機票預定系統會給用戶顯示錯誤提示并給出反饋，同時通知人工客服來進行進一步核實。( 出錯處理需求 )

在任何時刻機票預定系統中的服務器或備份服務器至少有一個是可用的，一個月內系統中的不可用時間不能超過系統運行總時間的3%。( 可用性需求 )

機票預定系統應該提供第三方的登錄和支付接口。( 接口需求 )

乘客不能預定同一時間點的多張機票。( 逆向需求)

機票預定系統需要按照國際化（用戶界面提供多種語言）進行開發。( 約束 )

機票預定系統應該為以后多家航空公司的入駐提供預留空間。(將來可能提出的需求 )
與用戶溝通獲取需求的方法

訪談

訪談是最早開始使用的獲取用戶需求的技術，也是迄今為止仍然廣泛使用的需求分析技術。

訪談有兩種基本形式，分別是正式的和非正式的訪談。

正式訪談

正式訪談時，系統分析員將提出一些事先準備好的具體問題，

例如，向間客戶公司銷售的商品種類、雇用的銷售人員數目以及信息反饋時間應該多快等。

非正式訪談

在非正式訪談中，分析員將提出一些用戶可以自由回答的開放性問題，以鼓勵被訪問人員說出自己的想法，例如，詢問用戶對目前正在使用的系統有哪些不滿意的地方。當需要調查大量人員的意見時，向被調查人分發調查表是一個十分有效的做法。經過仔細考慮寫出的書面回答可能比被訪者對問題的口頭回答更準確。分析員仔細閱讀收回的調查表，然后再有針對性地訪問些用戶，以便向他們詢問在分析調查表時發現的新問題。

情景分析技術

在訪問用戶的過程中使用情景分析技術往往非常有效。

所謂情景分析就是對用戶將來使用目標系統解決某個具體問題的方法和結果進行分析。

例如，假設目標系統是一一個制定減肥計劃的軟件，當給出某個肥胖癥患者的年齡、性別身高、體重、腰圍及其他數據時，就出現了一個可能的情景描述。系統分析員根據自己對目標系統應具備的功能的理解，給出適用于該患者的菜單。客戶公司的飲食專家可能指出，某些菜單對于有特殊飲食需求的患者(例如，糖尿病人、素食者)是不合適的。這就使分析員認識到，目標系統在制定菜單之前還應該先詢問患者的特殊飲食需求。系統分析員利月情最分析技術，往往能夠獲知用戶的具體需求。

情景分析技術的用處主要體現在下述兩個方面：

①它能在某種程度上演示目標系統的行為，從而便于用戶理解.而且還可能進一步揭示出一些分析員目前還不知道的需求。

②由于情景分析較易為用戶所理解,使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色。需求分析的目標是獲知用戶的真實需求，而這一信息的唯一來源是用戶.因此，讓用戶起積極主動的作用對需求分析工作獲得成功是至關重要的。

面向數據流自頂向下求精

軟件系統本質上是信息處理系統，而任何信息處理系統的基本功能都是把輸人數據轉變成需要的輸出信息。數據決定了需要的處理和算法、看來數據顯然是需求分析的出發點。在可行性研究階段許多實際的數據元素被忽略了，當時分析員還不需要考慮這些細節，現在是定義這些數據元素的時候了。

結構化分析方法就是面向數據流自頂向下逐步求精進行需求分析的方法。

通過可行性研究已經得出了目標系統的高層數據流圖，需求分析的目標就是把數據流和數據存儲定義到元素級。

為了達到這個目標，通常從數據流圖的輸出端著手分析,這是因為系統的基本功能是產生這些輸出，輸出數據決定了系統必須具有的最基本的組成元素。輸出數據是由哪此元索組成的呢?通過調查訪問不難搞清這個問題。

那么，每個輸出數據元素又是從哪里來的呢?既然它們是系統的輸出，顯然它們或者是從外面輸入到系統中來的,或者是通過計算由系統中產生出來的。沿數據流圖從輸出端往輸入端回溯應該能夠確定每個數據元素的來源，與此同時也就初步定義了有關的算法。

但是,可行性研究階段產生的是高層數據流圖.許多具體的細節沒有包括在里面，因此沿數據流圖回溯時常常遇到下述問題:

為了得到某個數據元素需要用到數據流圖中目前還沒有的數據元素,或者得出這個數據元素需要用的算法尚不完全清楚。

為了解決這些問題，往往需要向用戶和其他有關人員請教.他們的回答使分析員對目標系統的認識更深人更具體了，系統中更多的數據元素被劃分出來了,更多的算法被搞清楚了。通常把分析過程中得到的有關數據元素的信息記錄在數據字典中，把對算法的簡明描述記錄在IPO圖中。通過分析而補充的數據流、數據存儲和處理，應該添加到數據流圖的適當位置上。

必須請用戶對上述分析過程中得出的結果仔細地復查,數據流圖是幫助復查的極好工具。從輸入端開始，分析員借助數據流圖、數據字典和IP0圖向用戶解釋輸人數據是怎樣一步一步地轉變成輸出數據的。

這些解釋集中反映了通過前面的分析工作分析員所獲得的對目標系統的認識。

這些認識正確嗎?有沒有遺漏?用戶應該注意傾聽分析員的報告,并及時糾正和補充分析員的認識。

復查過程驗證了已知的元素,補充了未知的元素,填補了文檔中的空白。反復進行上述分析過程,分析員越來越深人地定義了系統中的數據和系統應該完成的功能。為了追蹤更詳細的數據流，分析員應該把數據流圖擴展到更低的層次。通過功能分解可以完成數據流圖的細化。

對數據流圖細化之后得到一組新的數據流圖,不同的系統元素之間的關系變得更清楚了。對這組新數據流圖的分析追蹤可能產生新的問題，這些問題的答案可能又在數據字典中增加一些新條目,并且可能導致新的或精化的算法描述。隨著分析過程的進展，經過提問和解答的反復循環,分析員越來越深人具體地定義了目標系統最終得到對系統數據和功能要求的滿意
了解。

下圖粗略地概括了上述分析過程。

簡易的應用規格說明技術

使用傳統的訪談或面向數據流自頂向下求精方法定義需求時,用戶處于被動地位而且往往有意無意地與開發者區分"彼此”。由于不能像同一個團隊的人那樣齊心協力地識別和精化需求，這兩種方法的效果有時并不理想(經常發生誤解，還可能遺漏重要的信息)。

為了解決上述問題，人們研究出一.種面向團隊的需求收集法，稱為簡易的應用規格說明技術。這種方法提倡用戶與開發者密切合作，共同標識問題，提出解決方案要素，商討不同方案并指定基本需求。今天,簡易的應用規格說明技術已經成為信息系統領域使用的主流技術。

使用簡易的應用規格說明技術分析需求的典型過程如下:

首先進行初步的訪談，通過用戶對基本問題的回答，初步確定待解決的問題的范圍和解決方案。然后開發者和用戶分別寫出“產品需求”。選定會議的時間和地點,并選舉一個負責主持會議的協調人。邀請開發者和用戶雙方組織的代表出席會議，并在開會前預先把寫好的產品需求分發給每位與會者。

要求每位與會者在開會的前幾天認真審查產品需求，并且列出作為系統環境組成部分的對象、系統將產生的對象以及系統為了完成自己的功能將使用的對象。此外,還要求每位與會者列出操作這些對象或與這些對象交互的服務(即處理或功能)。最后還應該列出約束條件(例如成本、規模、完成日期)和性能標準(例如速度、容量)。并不期望每位與會者列出的內容都是毫無遺漏的，但是，希望能準確地表達出每個人對目標系統的認識。

會議開始后,討論的第一個問題是,是否需要這個新產品，一旦大家都同意確實需要這個新產品,每位與會者就應該把他們在會前準備好的列表展示出來供大家討論。可以
把這些列表抄寫在大紙上釘在墻上，或者寫在白板上掛在墻上。理想的情況是,表中每一項都能單獨移動,這樣就能方便地刪除或增添表項，或組合不同的列表。在這個階段，嚴格禁止批評與爭論。

在展示了每個人針對某個議題的列表之后，大家共同創建張組合列表。 在組合列表中消去了冗余項，加人了在展示過程中產生的新想法,但是并不刪除任何實質性內容。在針對每個議題的組合列表都建立起來之后，由協調人主持討論這些列表。組合列表將被縮短、加長或重新措辭,以便更準確地描述將被開發的產品。討論的目標是，針對每個議題(對象、服務、約束和性能)都創建出一張意見致的列表。一旦得出了意見一 致的列表 ,就把與會者分成更小的小組，每個小組的工作目標是為每張列表中的項目制定小型規格說明。小型規格說明是對列表中包含的單詞或短語的準確說明。然后,每個小組都向全體與會者展示他們制定的小型規格說明，供大家討論。通過討論可能會增加或刪除一些內容 ，也可能進一步 做些精化工作。在完成了小型規格說明之后,每個與會者都制定出產品的一整套確認標準，并把自己制定的標準提交會議討論，以創建出意見致的確認標準。 最后,由一名或多名與會 者根據會議成果起草完整的軟件需求規格說明書。

簡易的應用規格說明技術并不是解決需求分析階段遇到的所有問題的“萬能靈藥”，但是，這種面向團隊的需求收集方法確實有許多突出優點:開發者與用戶不分彼此,齊心協力，密切合作;即時討論并求精;有能導出規格說明的具體步驟。

快速建立軟件原型

快速建立軟件原型是最準確、最有效、最強大的需求分析技術。快速原型就是快速建立起來的旨在演示目標系統主要功能的可運行的程序。構建原型的要點是，它應該實現用戶看得見的功能(例如屏幕顯示或打印報表)，省略日標系統的“隱含”功能(例如修改文件)。

快速原型應該具備的第–個特性是“快速”。快速原型的目的是盡快向用戶提供一個可在計算機上運行的目標系統的模型,以便使用戶和開發者在目標系統應該“做什么”這個問題上盡可能快地達成共識。因此，原型的某此缺陷是可以忽略的，只要這些缺陷不嚴重地損害原型的功能，不會使用戶對產品的行為產生誤解,就不必管它們。

快速原型應該具備的第二個特性是“容易修改”。如果原型的第一版不是用戶所需要的，就必須根據用戶的意見迅速地修改它，構建出原型的第二版,以更好地滿足用戶需求。在實際開發軟件產品時，原型的“修改一試用一反饋"過程可能重復多遍，如果修改耗時過多，勢必延誤軟件開發時間。

為了快速地構建和修改原型,通常使用下述3種方法和工具。

(1)第四代技術

第四代技術包括眾多數據庫查詢和報表語言、程序和應用系統生成器以及其他非常高級的非過程語言。第四代技術使得軟件工程師能夠快速地生成可執行的代碼，因此,它們是較理想的快速原型工具。

(2)可重用的軟件構件

另外一種快速構建原型的方法，是使用-組已有的軟件構件(也稱為組件)來裝配(而不是從頭構造)原型。軟件構件可以是數據結構(或數據庫)，或軟件體系結構構件(即程序),或過程構件(即模塊)。必須把軟件構件設計成能在不知其內部工作細節的條件下重用。應該注意，現有的軟件可以被用作“新的或改進的”產品的原型。

(3)形式化規格說明和原型環境

在過去的20多年中，人們已經研究出許多形式化規格說明語言和工具,用于替代自然語言規格說明技術。今天,形式化語言的倡導者正在開發交互式環境，以便可以調用自動工具把基于形式語言的規格說明翻譯成可執行的程序代碼,用戶能夠使用可執行的原型代碼去進一步精化形式化的規格說明。

總結

以上是生活随笔為你收集整理的【软件工程导论】习题集的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。