軟件工程課后習題答案中文翻譯版

軟件工程課后習題：

1.解釋為什么專業化軟件不僅僅包括為用戶所開發程序

專業化軟件在開發上與在與軟件就有所不同。專業軟件通常是由

團隊開發而非個人，除了開發者外還有其他的用戶使用。如果你的軟

件有別的用戶，別的工程師會去修改的話，你就必須提供除了程序源

碼之外的其它附帶信息。因此，系統通常除了包含一些單獨的程序還

有用于這些程序的配置文件，可能還包括描述系統結構的系統文檔和

解釋如何使用該系統的用戶文檔，以及告知用戶下載最新產品的Web

站點。

2.通用軟件產品開發和定制軟件開發直接有什么不同這在實際應

用中對通用軟件產品用戶意味著什么

(1)重要區別為：在通用軟件的開發過程中，詳細說明(規格說

明書)由產品開發者來制定，在定制軟件產品開發過程中，詳細說明

(規格說明書)由客戶來制定開發者必須按客戶要求進行開發。

(2)意味著通用軟件很難滿足通用軟件客戶的特殊需求。如可靠

性、安全性、快捷性。

3.軟件產品應該具有與的4重要屬性是那些另外列舉出4個可能有

意義的屬性。

重要屬性：可維護性、可依賴性和安全性、有效性和可用性?？?/p>

能有意義的屬性:可復用性、可分發性、可移植性和互用性。

4.除了異質性挑戰、業務和社會的變革、安全和可信，說出軟件

工程在21世紀的可能面臨的其它問題和挑戰。

交付上的挑戰：許多傳統的軟件工程技術需要耗費大量的時間，

用于提高軟件質

量。而今天的軟件制作必須響應快、更換迅速，支持軟件也必須

同樣快地進行更換。交付上的挑戰是：在不損及系統質量的前提下，

縮短大型、復雜系統的移交時間。

5.參論的應用類型，照節討舉例介紹為什么設計和開發不同類型

的應用需要專門的軟件技術。

如汽車上年的嵌入式控制系統對安全性要求極高，在車上安裝是

要燒制到ROM中在這里的交互在這里是很少的(或許根本就沒有)。

基于Web式系統更適合用于迭代式開發和交互。而基于Web的系統

編程使用的如Ruby一類的腳本語言,完全不適合嵌入式系統工程。6.

解釋為什么軟件工程的基本思想適用于所有的軟件系統。

軟件工程的基本思想：1,應使用有管理和理解了的開發過程進行

開發。2.可依賴性和性能對所有類型的系統來說都很重要。3.理解和管

理系統描述和需求是很重要，你必須知道不同的客戶和用戶的期望是

什么。4贏盡可能搞笑地使用檔期存在資源。

軟件工程也是從無數實踐中提煉出來的一門科學，溝通、需求分

析、設計建模、編程、測試和支持都是軟件工程方法所依賴于一組的

本原則。這些思想和原則涵蓋了軟件工程所有技術，是軟件開發不可

缺少的一部分。所以軟件工程的基本思想適用于所有的軟件系統。

7.解釋Web的普遍使用是怎么改變軟件系統的。

(1)軟件復用已經成為構建基于Web的系統的主要技術。當你

在夠著這樣的系統是就需要考慮在學校恩怨從已有的軟件組件和系統

開始工作。

(2)基于Web的系統的開發和交付應逐步完成，提前制定這些

系統的所以需求

是不切實際的。

(3)用戶界面搜到瀏覽器能力和實用性約束，基于Web的系統

上的應用界面通常比專門為Pc系列產品專門設計的用戶界面要差。

(通俗點講就是：實用是實用，就是有點丑。)

8.職業人員是否應該和醫生或律師一樣要頒發資格證書討論一下。

我認為：可以給職業人員頒發某種軟件技術方面的資格證書以便

公司能夠快速確認從業人員具備的技能和讓社會大眾對從業人員的技

術資質有更簡單直觀的了解。當然，這個證書不能成為他職業道德的

證書，軟件工程從業人員的職業道德和行為準則因由此方面協會和機

構引導，從業人員自己嚴加自律。

9.對吐1?3的ACM/IEEE職業道德準則中的每一條款，舉出一個

恰當的例子加以說明。

(1)公眾感：軟件工程從業人員應該始終與公眾利益保持一致。

不應該通過軟件給某些利益集團謀取私利從而損害廣大人民群眾的利

益。

(2)客戶和雇主:不能只站在雇主這邊為雇主最求利益最大化而

不顧客戶利益。(3)產品：不能做一個沒有完成或某方面如安全性、

穩定性未達標的產品給客戶。(4)判斷力：軟件從業人員應具備達到

判斷力，知道自己做的產品不是刻意用來危害社會的。

(5)管理：合理管理軟件開發方法，不能官僚主義全聽領導一句

話。(6)職業感：大家都是從事正當行業的，要多想想怎么為社會謀

取福利。

(7)同事：黑社會都說以和為貴,團隊成員都是奔著一個目標去

的不要由于一些小小分歧就那個啥…周恩來說要求同存異。

(8)自己：注意要有健康積極的職業和生活方式。

什么是四個重要的屬性，所有的軟件產品應該有建議四其他屬性,

有時可能是重要的?？删S護性，可靠性，有效性,可用性.Other可復用性，

可分發性，可移植性，互用性

給你的答案基于系統正在開發的類型的原因，建議最適當的通用

的軟件過程模型，可以用來管理跟蹤系統發展的基礎：

1)防抱死制動系統2)的虛擬現實系統3)高校會計制度4)互

動的時間表(一)防抱死制動系統：安全關鍵安全鑒定系統方法的基

礎上，正式的轉換等價每段之間的等價證明。(b)的虛擬現實系統：

系統的要求，事先無法預測預先地預知所以探索性編程模型是合適的。

(C)大學會計系統：系統的要求應穩定是因為現有的系統因此瀑

布模型是合適的。

(d)互動的時間表交互式時間表：系統復雜的用戶界面，但它必

須是穩定的，可靠的。應根據丟棄原型找到要求然后增量開發或瀑布

模型。

為什么一個軟件系統，用一個真實的世界環境必須改變或成為

progressivelyless有用嗎

這種適應自然生成新的系統需求

系統的環境是動態的，不斷產生新的要求，作為對業務變化的后

果，業務目標和業務政策。商務的目標以及政治相關除非系統適于反

映這些要求，其設施將成為了所需要的設施支持業務和步驟，因此，

它將變得不那么有用。

為什么一個好的程序員不一定是一個好的軟件管理者

管理活動包括提出書面建議，項目規劃和進度，人員選擇和評價，

項目監督和評審，和其他隊友的交流能力等。程序設計者的任務就不

是這些，他們不需要和人交流的能力，如果按照做好一個程序設計者

的要求去做管理者的話，他肯定不是一個號的管理者。

為什么項目策劃的過程是迭代的，為什么一個計劃必須不斷審查

軟件項目中。軟件項目地規劃取決于有用地信息。在項目進行期間不

斷產生新的信息，所以必須經常性的修改原有的計劃。原本有用的信

息可能會不再有用，而原本一些

不確定的信息反而會變得有用。最初對象目本身的估算是實驗性

的，所以計劃需要不斷的修改。

表明他們可能會在一所大學的學牛記錄系統中的利益相關者。

在一個學生記錄系統的利益相關者包括：大學管理中心，包括報

到，交納學費，考試，作業和畢業等記錄在這個系統中的學生

大學部門管理者，需要提供和使用這些信息

使用系統信息的學院成員

數據保護工作者

潛在的學生中的雇傭者

在學生記錄系統中的參與者包括：

O學校管理中心包括負責學生注冊，繳費，考試，評估，畢業事

宜的相關人員。那些被記錄具體信息的學生

o把學生信息錄入到系統并使用系統信息的學校部門人員

o使用這些信息的學術人員

。數據安全人員（木順口國家的）

o潛在的雇用學生的人（或許需要用到這個系統里面的信息）

三在圖書館系統中發現的觀點。libysy,建議三的要求，可以通過

與相關的利益相關者提出的觀點。你可以解決這個問題用頭腦風暴的

方法。顯然，有許多替代解決方案建議，這里。注意印刷沖突是故意

的。

觀點：圖書館管理

要求：進入匯文系統應限于認可的圖書館用戶。

要求：在匯文系統必須提供一個報告的設施，允許使用報告（誰

使用系統，多久，是什么庫訪問）來創建和打印。

要求：在匯文系統的配置應使特定的庫服務器允許打印文檔。

觀點：用戶

要求：在匯文系統應可從任何位置，包括地點離大學校園。

要求：應能保存匯文系統查詢，回憶和修改后使用。

要求：在匯文系統應允許文件被打印在用戶的打印機。

觀點：系統管理員

要求：重新啟動時間的匯文系統失敗后不得超過5分鐘。

要求：在匯文系統必須提供一個用戶的個人工作空間的備份設備。

要求：在匯文系統應提供一系列平臺包括Windows2000,

和

WindowsXPMACOSXo

匯文系統支持包括編目工作的新文件系統目錄可以分布在多臺機

器?？赡苁欠枪δ苄枨笈c編目設施有關的最重要的類型

重要的非功能屬性的編目服務的可能：

可用性（因為系統可以在任何I需要的時間）

安全（因為圖書數據庫不能損壞）

效率（因為系統必須迅速作出反應，每個交易）

為瀏覽服務，這些服務的可用性也是非常重要的應該是易于使用，

沒有廣泛的培訓。

討論了一個例子，一個類型的系統的社會和政治因素可能強烈地

影響系統的要求。解釋為什么這些因素是重要的在你的例子。

社會和政治因素影響系統需求的一個例子是管理成木和公共衛生

保健的系統。政治家們對控制成本和確保提供最好的衛生保健系統都

很關心。在這樣一個系統中這本來就是一對潛在的矛盾，系統管理人

員關心的治療成本而醫生們關心的治療效果。此時系統需求可能要建

立在特殊的包括一系列組織因素的政策上而不是技術需求。

為什么它可能需要在規范設計系統的體系結構是寫的嗎

體系結構設計過程輸出了一個體系結構的設計文檔，這樣的設計

文檔包含了一系列圖形化的系統模型描述和一些相關的描述文本。該

文當描述了系統如何有子系統構成以及每個子系統如何有模塊構成。

給你答案的原因，建議以下系統的一個合適的結構模型：

一個在鐵路站旁，供乘客使用的自動售票系統

答：自動售票系統。最合適的架構模型是有共享數據倉庫和定價

信息的集中式控制模型。當使用這種模型時，所有機子能立即獲取改

變的信息。由于沒有局部處理的必要，所以使用客戶/服務架構沒有什

么優勢。集中式控制系統允許全局信息和路徑被收集和處理。

一個允許在同一時間段，視頻，音頻，計算機數據對很多參與者

是可見的計算機控制視頻會議系統答：視頻會議系統。最合適的是使

用客戶/服務模型。很多局部過程用來處理多媒體數據。

一個清潔機器人，主要用來清理一些地方比如走廊。該清潔機器

人必須能感應墻和其他的障礙物。答：清潔機器人。最適合的模型是

貯藏式模型。這時所有的子系統把信息存放在其他子系統得貯藏室，

以備后用。以AI系統為例，一種特殊的貯藏室叫做〃黑板〃被使用

就分布性討論數據流模型和對象模型的優點和缺點。假設應用程

序的淡季和分布式版本都是必需的。

兩種模型都能作為分布式，數據流程圖中的每個轉換都可以看作

是個分離的過程，而每個對象也可以作為過程實現。函數的分解需要

共享狀態，并表示為一

個或多個過程。在對象模型中分布對象是個問題，對象如果繼承

的話就如同它的創建一樣會造成很多網絡阻塞。

用例子，解釋對象和對象類之間的不同。

對象類就是定義實體（或者說對象）的類型說明，包含可以被識別的

相似的公共特征。對象是真實世界或是在系統中的通過對象類對其屬

性進行賦值的特殊實例。給對象的賦值操作可用于識別與其他所有對

象的區別，盡管不需如此。在現實世界中，我們只能看到對象和作為

抽象實體的構造對象類。在程序中，我們通常可以定義對象類和構造

對象，它們的聲明周期不超過程序的執行時間。

一個對象類的一個實例，是一本具有的屬性（特征）如標題，作

者，出版社，出版日期，等。

一個叫做"BOOK〃的對象類的例子，屬性有諸如……

一個關于這個對象類的對象的例子"specificbook"

作者：伊恩薩默維爾標題：軟件工程版：7出版商艾迪生衛斯理

如果我們想定義一個書的對象是不同于其他所有的對象，我們需

要增加的另一個特點的對象類，如業主。

說明在什么情況下提供前后一致的用戶界面是不明智的或是

不可能的。

一致性的用戶界面也許不可能提供給擁有大量選項的復雜系統。

在這樣的系統中，經常使用的不同命令的使用程度有很大差異，因此

我們希望用快捷方式。除非所有的命令都有快捷方式，否則一致性的

界面是不可能的。

此外在復雜的操作界面中有不同類型的操作實體，這些不同類型的

操作實體擁

有相同的操作是不可能的。

開放型操作系統就是這樣一個系統的例子。甚至是竭力做到盡可

能一致性界面的蘋果操作系統（MacOS）都會根據不同的用戶喜好而由

此產生矛盾。

再舉個例子，用戶要刪除一個文件，只要把它拉到垃圾回收站，

而刪掉一個磁盤映像可不能這樣，那要卸載那個磁盤。

在為〃臨街的〃系統（如ATM機）涉及基于菜單的界面時，必須考

慮哪些因素請對你所使用的ATM機的界面提出批評意見。

要考慮的因素在設計步行和使用的系統：

系統的用戶可能是虛弱的，或禁用，因此將無法快速響應的要求。

用戶可能無法講母語的國家機器安裝。

系統的用戶可以與技術完全陌生的，可以用機器做幾乎任何類型

的錯誤。接口必須盡量減少可能出現的錯誤的數量必須是有彈性的任

何可能的錯誤。？一些系統的用戶可能是由許多選項嚇倒。另一方面，

當用戶與系統增益的熟悉，他們可能會使用一系列的銀行服務。

不同的人可能會明白不同圖標的含義。

如果系統導航選項，用戶幾乎肯定是迷路了。

大多數用戶將要使用的系統很簡單的功能（例如提取現金取款機）

和將要這樣做，盡快。

有許多不同的ATM接口，每個人都必須單獨考慮。我所發現的問

題是：當有可能取消交易嗎當我這樣做時會發生什么如果我重新啟動

事務必須重新輸入什么通常是不存在任何的方式說給我的最大數額的

錢我可以撤回今天。有些機器只支持單一的交易是沒有辦法說我會做

一些交易和相同的驗證過程是適用于所有的人

試述圖形顯示的優點，指出適合用圖形顯示數值而不適合用數字

顯示的四種應用。優點是匆匆一眼就能獲得數值暗示和相對數值暗示。

這里有四個適于圖形顯示信息,而不適用于數字顯示信息的例子.

溫度計速度指示器氣候統計表一些相關的比較表格.

你在什么情況下會建議不采用敏捷方法進行軟件系統開發

當幾個軟件開發團隊不在同一個地方時不可用敏捷方法。如果其

中一個團隊用了敏捷方法,就很難跟其它團隊協調工作.敏捷方法也要避

免用在關鍵系統，在規格錯誤的情況下如果用這個方法，會導致嚴重的后

果.在開發系統之前規格就可以用的情況下，可以做詳細的規格分析使用

敏捷方法成為可能.然而，一些敏捷方法中的思想像測試優先開發（Test

FirstDevelopment-TFD又稱先行測試開發）當然是可以適用于關鍵系

統的.

解釋為什么測試優先開發能幫助程序員獲得對系統需求的更好的

理解。測試優先的開發有什么潛在的困難。

測試優先開發將助我們更好地理解需求，因為你要寫一個測試程

序，就需要分析需求，探究詳細意圖。

有時候，在需求不全的情況下，你會發現寫一個測試是不可能的。

測試優先開發的問題就在于是一些測試很難寫，因為在任何一個測試

之前都要一個就緒的系統底層結構.

給出四個理由說明為什么結對編程和單個程序員編程的軟件生產

率基本上是一樣的。

結對編程和同等數量的編程人員單獨編程一樣有效的原因：

1.結對編程會引發連續非正式地復查，這樣會比單獨編程更快地

發現錯誤。

2.結對編程過程中，信息是共享的。單獨編程中，人們不得不花

時間來共享信息。

3.結對編程鼓勵重構（代碼需要讓其他人看懂），這樣減少了后

期開發和變動的成本。

4.結對編程可能花更少的時間在細節優化上，因為這對其他程序

員來說沒有好處。（譯者注：沒看懂）

假設一個軟件管理者參與了一個開發某個軟件設計支持系統的項

目，此系統是要支持將軟件需求翻譯成形式化軟件描述。請評論下列

開發策略的優點和缺點。

開發拋棄式原型，評估，然后審查系統需求。用C語言開發此系

統。

丟棄原型化方法:快速的開發和快速的用戶反饋.可以帶來合理的需

求

需要多種開發語言.花費更高.

適用java從現存的需求開始開發系統，然后修改它使之適應任何I

變更的用戶需求。

開發使用C和X-Windows培訓較少的問題。

已知的管理策略。需求可能的錯誤需要交付后的改性。訓練幾乎

沒問題，已知的管理策略.需求可能的錯誤的，所以要交付修改.

適用增量式方法并讓用戶參與到開發團隊來開發此系統。

進化的方法.快速的用戶反饋.快速的系統交付.容易適應改變的需求.

很難管理,缺少可移植性的標準.無特定系統結構，將導致以后的維護

困難.

解釋下為什么通過復用已有的軟件所節省的成本并不簡單地與所

適用的組件規模成比例。

如果復用節約的成本和復用的代碼成比例，那么復用2000行代碼

就相當于復用兩次1000行代碼了。然而，復用2000行代碼，那些代

碼必須要被理解，程序理解的費用不是線性的——越多的代碼，就需

要越多的努力去理解的。

而且，當需要更多的改動時，就需要更大量的代碼復用，這也增

加了成本。

給出你認為不應該適用軟件復用的4種情況。

一如果代碼提供商的運作狀況不確定，或者提供商歇業，不支持

代碼的復用。

二關鍵部分的代碼不可用。要測試這些代碼以達到所需標準，可

能非常困難。

三再利用所花的成本和再利用所節省下來的差不多的小型系統

四在一些關鍵需求在于性能的系統里，專門開發的代碼通常更有

效率。為什么模式是一種有效的設計復用形式這種復用方式的缺點是

什么

模式是一種有效的再利用設計,是因為它是很多人在應用中積累出

來的智慧.這種方法有兩種缺點：

知道哪一個模式被存檔，找到這些模式所花的時間是必要的.

2彳艮多模式是一般化的，很多性能可能被限制.如果性能是主要要求

的話，那么

為某一個問題問題特別研究的方法總是更有效率的.

XXX確定了六個可能的風險時可能出現的系統被構造使用COTS。

公司可以采取什么步驟來降低這些風險呢

風險時可能出現的系統被構造使用COTS包括：

賣主風險:賣方無法提供必要的支持,賣方歇業或結束產品開發.

產品風險:和其它系統不兼容,和其它系統組裝時性能下降，在特定環

境下,產品不可靠.

過程風險:理解如何組裝產品的時間超出預期.

可以通過使用第三方系統來解決.這樣的話，可以通過深入的研究投

入使用前的產品兼容性的測試,和其它用戶討論等方法來保證源代

碼的可用,如果賣方歇業的話.

通常,COST是由賣方提供的，要減少風險是困難的.

為什么它是重要的，所有組件的交互是通過定義的〃需要〃和

〃提供〃接口

它是通過定義所有的相互作用重要的需要提供接口，組件的使用

是完全獨立的，它的實現。如果組件交互使用的一些知識的組成部分,

是沒有定義的要求/提供接口，然后組件之間的耦合增加，很難交換一

個具有相同接口的等效組分的一個組成部分。

之間的根本區別是什么組件和Web服務（seeChapter12）.

Web服務只有單一的一個標準，組件則有多個標準，因此服務的

內部操作性會更好。

服務的付費是按使用權計算的（你要用時再付費，不用時，可以

停止付費），這樣用戶就不用為一個偶爾使用的組件，支付昂貴的費

用。

組件的交互可以作用比Web服務更有效的協議，因此組件更適用

于高吞吐量/高性能要求的應用。

一旦一個組件被購買，它就屬于用戶所有。而與此相反，Web服

務總是被提供商擁有，這就意味著用戶對于服務的更改永遠沒有控制

權，如果服務變更（或消失），那么可能對用戶很不利。而組件不同，

用戶可以決定什么時候使用新版本。

解釋為什么它是很難不組件源代碼驗證的可重用的組件。以什么

樣的方式將一個正式的組件規范簡化驗證的問題

因為在沒有源代碼的情況下，我們無法知道該組件是如何處理異

常的。唯一的辦法就是黑盒測試。因為組件的詳細規格說明書很少是

完整的，黑盒測試也有很大的困難。標準的詳細規格說明書定義了組

件的功能，盡管能提供一定的幫

助，但是標準的說明書也很少說明全部的異常，它并不能幫助我

們測試組件的性能，可靠性或其它的非功能性特征。

使用的例子，說明需要支持順序組成的適配器類型不同，分層的

組合物和添加劑的組合物。

順序組合的例子：部件C是由部件A和部件B依次組合而成的。

附加組合的例子：部件C是由部件A的界面和部件B的界面組成

的。

層次組合的例子：部件C是由部件B組成的，而部件B是由部件

C組成

的。

解釋為什么測試只能檢測到錯誤的存在，而不是他們的缺席。

假定窮舉測試的程序，在每一個可能的有效輸入檢查，是不可能

的（適用于所有但平凡的程序）。測試用例不顯示故障在程序或顯示

一個程序故障。如果他們發現一個程序故障則證明錯誤的存在。如果

他們不顯示故障，然而，這只是意味著他們已執行的代碼序列，-為輸

入-是不是錯誤的選擇。在相同的編碼序列-不同輸入-下測試可以揭示

故障。

回歸測試是什么解釋鋤自動化測試的使用和測試框架，如單元簡

化回歸測試?；貧w測試是指修改了舊代碼后，重新進行測試以確認修

改沒有引入新的錯誤或導致其他代碼產生錯誤。如果設置了自動回歸

測試，在每次修改代碼之后都會自動進行測試，簡化了回歸測試的工

作。一個自動化的測試包括成功的自身測試和其他測試。這樣成功的

測試成本和回歸測試成本較低。

在一個分布式數據庫系統，如LIBSYS開發性能測試的問題是什么

在軟件測試一個系統中碰到的主要問題是：

在實際中你不能重復測試一個系統，所以你必須用一個模擬器來

模擬系統的使用。然而，你沒有系統實際工作的經驗，用一個模擬器

很難測試系統工作時的準確性。

2.LIBSYS系統不一定在專用的電腦上工作—該系統也可以同時

在其他應用系統上工作。其他應用系統也會影響整個分布式系統的工

作。在測試的時候，這些情況不會重復發生。

3.事實上數據的分布是未知的。數據分布受到特定的服務器的影

響，所以對于數據的最初的假設可能是錯誤的。

解釋為什么接口測試是必要的甚至在個別組件已被廣泛驗證通過

組件測試和程序檢查。

在單元測試后接口測試的重要性：

①單元的接口可能沒有明確的說明。確認這個單元的接口是以他

的詳細規格說明書為基礎而不是以單元或者子系統在實踐中的使用為

基礎的。

②假設了某些西元的操作，接口測試可以檢測由這些單元組成的

接口是否正確，有效。

③接口測試可以揭示在接口設計時的遺漏和錯誤。當接口和其他

的單元組合在一起的時候這些錯誤會被發現，那么這些遺漏和錯誤可

以被加到這個接口中。

在什么情況下會公司收費軟件系統比建議的費用估計加正常利潤

更高的價格

①客戶要開發者自己承擔大部分的項目風險。

②客戶有一些苛刻的要求，比如開發的時間比較短，要快速開發。

③開發軟件這個工作不是公司主要的業務，所以為了開發項目必

須從其他的業務上調派人手過來，那么就需要補償給這些人更多的錢。

④客戶很自私，只考慮到自己不能承擔太多的錢。

描述兩個已被用來衡量程序員生產率度量。簡要評述了各自的優

點和缺點，這些度量。

已用于生產的測量指標：

源代碼行的每單位時間產生的

目標代碼指令的每單位時間

頁的每單位時間的文件其他的可能性是：

數據字典條目每單位時間?數（可能是有用的如果使用CASE工具）

數學定義的每單位時間產生的?數（規范）

書面的每單位時間的要求?數

設計圖的每單位時間產生的?數

所有這些，當然，遭受同樣的問題，其他指標，那就是，他們不

考慮質量因素。

解釋如何成本估計算法可以由項目經理進行期權分析。建議的情

況下，管理者可以選擇一種方法，不是基于最低工程造價。

使用算法模型進行項目估算，估算者應該做一系列估算（最壞估

算，期望估算和最好估算）而不是單一估算，并用成本計算公式都計

算一遍。管理者要估算軟件的開發周期以及其他過程和產品因素的估

算，比如團隊隊員的工作經驗，硬件設備的更新，購買開發工具等。

建立一張工作表，這張表包括了這些變化所產生的影響，并對這些影

響進行估算。

由于一些組織機構方面的原因，管理者可能會選擇一些相對比較

貴的技術或者方法。比如軟件工程師的經驗相對比較豐富，但是工資

也會比較高，但是開發人員還是會選擇軟件工程師來作為自己團隊的

成員而不使用新人。

試列舉三個為支持機構過程改善項目而開發的專門軟件工具）

Elapsedtime經過時間。做某事需要多長時間。許多可能的例子

如時間進行設計評審。

Resourceutilisation.資源禾U用率。大量的資源使用。如工作需要

測試模塊。

Eventswhichoccur.事件的發生。例如，一個系統已交付后發現

的缺陷數。

解釋為什么在明確配置管理系統的文檔時不用文檔的名字，提出

一個標準文檔識別目錄可用于組織中的所有工程。）

標題不是唯一的，所以不能用來標識文檔。不同的子項目中的文

檔可能含有相同的標題。

文檔標識的標準：〈項目名稱〉＜子項目名稱＞＜任務名稱＞＜文檔

類型〉〈文檔號碼＞＜版本號＞＜數據〉

一個里程碑和可交付的關鍵的區別是什么

里程碑是一個活動過程的終點。在每一個里程碑，應該有一個正

式的輸出，如報表，可以提出管理。里程碑報告不需要大的文件。他

們可能只是一個已完成的內容簡短的報告。里程碑應該代表一個獨特

的結束，在項目的邏輯階段。

可交付成果是項目成果交付給客戶。它通常是在一些重大項目相

如規格或設計底交貨?？山桓冻晒峭ǔ５睦锍瘫?，但不需要交付的

里程碑。

為什么風險管理是軟件工程的重要

軟件項目風險管理是特別重要的，因為大多數項目所面臨的不確

定性因素。這些來自松散定義的要求，估計軟件開發所需的時間和資

源的困難，在個人的水平和要求的變化，由于變化在客戶的依賴需求。

什么是一個可行性研究解決

可行性研究決定提出的系統是否是值得的。如果系統有助于組織

的目標；

如果系統可以設計使用目前的技術和預算范圍內；如果系統能夠

與其他系統，使用集成。

（可能是計算機系統，也可以是手工的系統）

描述了用戶界面設計的原則.P364

熟悉一致性（最小詫異）（可復原性）（指導性）（多樣性）

在這一過程中的3個核心活動：

用戶分析。了解用戶與系統；系統原型。開發了一系列的原型實

驗；界面評價。這些原型與用戶體驗。

HowtoanalysistheuseractivitiesintheUIdesign

processP378

在軟件開發中的增量方法的優點是什么P393

1.客戶服務的快速交付。每個增量提供最高優先級功能給客戶。

與系統用戶的參與。用戶必須參與發展，這意味著系統更容易滿

足他們的要求，用戶更致力于系統。

討論了增量式開發和原型之間的區別P395

增量關系的發展提供一個工作系統的最終目的。開始開發這些要

求是最好的理解。

目的丟棄原型是驗證或派生的系統要求。成型過程開始與這些要

求了解甚少。

結對編程的優勢是什么P404

對程序的使用有許多優點：

它有助于發展共同擁有的代碼和傳播知識在團隊。

它作為一種非正式的審查過程的每一行代碼都是看了超過1人。

它鼓勵重構整個團隊可以受益于此。

原型如何可以用在軟件開發過程中什么是使用原型的好處p409-

411

一個原型可用于：

需求工程過程幫助的需求獲取和驗證；

在設計過程中探索和開發用戶界面設計；

在測試過程中運行的背靠背試驗

效益的原型

提高系統的可用性。

更符合用戶的實際需求。

提高設計質量。

改進的可維