19.1用自己的話，描述為什么在面向?qū)ο笙到y(tǒng)中，類是最小的合理測(cè)試單元。

答：在面向?qū)ο筌浖?#xff0c;單元的概念發(fā)生了變化，不再是傳統(tǒng)軟件單元測(cè)試中關(guān)注的算 法細(xì)節(jié)和流經(jīng)模塊接口數(shù)據(jù)，而是測(cè)試由封裝在類中的操作和類的狀態(tài)行為驅(qū)動(dòng)。最小的可 測(cè)試單元是封裝了的類，一個(gè)類包含了不同的操作，而一個(gè)操作也是有不同的類組成的，傳 統(tǒng)的單元測(cè)試已經(jīng)不再能滿足面向?qū)ο筌浖奶攸c(diǎn)了，而以類作為最小的測(cè)試單元更加合理。

19.8運(yùn)用隨機(jī)測(cè)試、劃分方法、多類測(cè)試及19.5, 19.6節(jié)所描述的銀行應(yīng)用的行為模型導(dǎo) 出的測(cè)試，在另外生成4個(gè)測(cè)試。

答：隨機(jī)測(cè)試：

測(cè)試用 例 r1 ：?open-setup-deposit-summarize-withdraw-close

劃分方法：

測(cè)試用例 r2：?open-setup-deposit-creditLimit -withdraw-close

多類測(cè)試：

測(cè)試用例 r3：?verifyAcct-verifyPIN-verifyPolicy-depositePeq

從行為模型導(dǎo)出的測(cè)試

測(cè)試用例 r4：?open-setupAccnt-deposit(initial)-withDraw-deposit-credit-accntInfo

-withdrawal(finial)-close

20.13導(dǎo)航語法測(cè)試與導(dǎo)航語義測(cè)試的區(qū)別是什么？

導(dǎo)航語法測(cè)試：確保允許WebApp用戶經(jīng)由WebApp游歷的機(jī)制都是功能性的。對(duì)導(dǎo)航功能進(jìn)行測(cè)試，以確保每個(gè)導(dǎo)航都執(zhí)行了預(yù)計(jì)的功能。

導(dǎo)航語義測(cè)試：確認(rèn)每個(gè)導(dǎo)航語義單元（MSU）都能被合適的用戶類獲得。“一組信 息和相關(guān)的導(dǎo)航結(jié)構(gòu)，在完成相關(guān)的用戶需求的子集時(shí)，這些導(dǎo)航結(jié)構(gòu)會(huì)相互協(xié)作"。每個(gè) NSU有一系列連接導(dǎo)航節(jié)點(diǎn)的導(dǎo)航路徑定義。作為一個(gè)整體，每個(gè)NSU允許用戶獲得特殊 的需求，這種特殊的需求是針對(duì)某類用戶，有一個(gè)或多個(gè)用例定義的。導(dǎo)航測(cè)試應(yīng)檢査每個(gè) NSU,以確保能夠獲得這些需求。

20.17為使其成功，CornerPharmacy.com已經(jīng)實(shí)現(xiàn)了一個(gè)特殊的服務(wù)，單獨(dú)處理處方的重 新填寫。平均情況下，1000個(gè)并發(fā)用戶每?jī)煞昼娞峤灰淮沃靥钫?qǐng)求，WebApp下載500B 的數(shù)據(jù)塊來響應(yīng)。此服務(wù)需要具有的吞吐量是多少Mb/s?

答： 吞吐量P=N*T*D

=（1000*0.5*500B） /60

=4167B/s

=0.033Mb/s

20. 18負(fù)載測(cè)試與壓力測(cè)試之間的區(qū)別是什么？

答：壓力測(cè)試主要是為了發(fā)現(xiàn)在一（任意）定條件下軟件系統(tǒng)性能的變化情況，通過改 變應(yīng)用程序的輸入以對(duì)應(yīng)用程序施加越來越大的負(fù)載（并發(fā)，循環(huán)操作，多用戶）并測(cè)量在 這些不同的輸入時(shí)性能的改變，也就是通常說的概念：壓力測(cè)試考察當(dāng)前軟硬件環(huán)境下系統(tǒng) 所能承受的最大負(fù)荷并幫助找出系統(tǒng)瓶頸所在。其實(shí)這種測(cè)試也可以稱為負(fù)載測(cè)試，但是負(fù) 載測(cè)試通常描述一種特定類型的壓力測(cè)試——增加用戶數(shù)量以對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試。比 如實(shí)際中我們說從比較小的負(fù)載開始，逐漸增加模擬用戶的數(shù)量，直到應(yīng)用程序響應(yīng)時(shí)間 超時(shí)，就是說的負(fù)載測(cè)試。

壓力測(cè)試的目標(biāo)是測(cè)試在一定的負(fù)載下系統(tǒng)長(zhǎng)時(shí)間運(yùn)行的穩(wěn)定性,尤其關(guān)注大業(yè)務(wù)量情 況下長(zhǎng)時(shí)間運(yùn)行系統(tǒng)性能的變化（例如是否反應(yīng)變慢、是否會(huì)內(nèi)存泄漏導(dǎo)致系統(tǒng)逐漸崩潰、 是否能恢復(fù)）；壓力測(cè)試是測(cè)試系統(tǒng)的限制和故障恢復(fù)能力，它包括兩種情況：

（1）穩(wěn)定性壓力測(cè)試：在選定的壓力值下，長(zhǎng)時(shí)間持續(xù)運(yùn)行。通過這類壓力測(cè)試，可以 考察各項(xiàng)性能指標(biāo)是否在指定范圍內(nèi)，有無內(nèi)存泄漏、有無功能性故障等；

⑵破壞性壓力測(cè)試:在穩(wěn)定性壓力測(cè)試中可能會(huì)出現(xiàn)一些問題，如系統(tǒng)性能明顯降低， 但很難暴露出其真實(shí)的原因。通過破壞性不斷加壓的手段，往往能快速造成系統(tǒng)的崩潰或讓 問題明顯的暴露出來；

負(fù)載測(cè)試的目標(biāo)是測(cè)試在一定負(fù)載情況下系統(tǒng)性能（不關(guān)注穩(wěn)定性，也就是說不關(guān)注長(zhǎng) 時(shí)間運(yùn)行，只是得到不同負(fù)載下相關(guān)性能指標(biāo)即可）；實(shí)際中我們常從比較小的負(fù)載開始， 逐漸增加模擬用戶的數(shù)量（增加負(fù)載），觀察不同負(fù)載下應(yīng)用程序響應(yīng)時(shí)間、所耗資源， 直到超時(shí)或關(guān)鍵資源耗盡，這就是所說的負(fù)載測(cè)試，它是測(cè)試系統(tǒng)的不同負(fù)載情況下的性能 指標(biāo)。

負(fù)載測(cè)試與壓力測(cè)試的最主要區(qū)別：

（1） 負(fù)載測(cè)試在于確定最終滿足系統(tǒng)指標(biāo)的前提下，系統(tǒng)所能承受的最大負(fù)載測(cè)試。

壓力測(cè)試的目標(biāo)則在確定什么條件下系統(tǒng)性能處于失效狀態(tài)

（2） 壓力測(cè)試主要是為了發(fā)現(xiàn)在一（任意）定條件下軟件系統(tǒng)性能的變化情況，通過改 變應(yīng)用程序的輸入以對(duì)應(yīng)用程序施加越來越大的負(fù)載（并發(fā)，循環(huán)操作，多用戶）并測(cè)量在 這些不同的輸入時(shí)性能的改變，也就是通常說的概念：壓力測(cè)試考察當(dāng)前軟硬件環(huán)境下系統(tǒng) 所能承受的最大負(fù)荷并幫助找出系統(tǒng)瓶頸所在.

負(fù)載測(cè)試通常描述一種特定類型的壓力測(cè)試——增加用戶數(shù)量以對(duì)應(yīng)用程序進(jìn)行壓 力測(cè)試。比如實(shí)際中我們說從比較小的負(fù)載開始，逐漸增加模擬用戶的數(shù)量，直到應(yīng)用程 序響應(yīng)時(shí)間超時(shí)。

22.6研究某現(xiàn)有的SCM工具，然后大概描述它是如何實(shí)現(xiàn)版本控制和配置對(duì)象控制的。

答：版本控制：SCM工具記錄項(xiàng)目和文件的修改軌跡，跟蹤修改信息，使軟件開發(fā)工 作以基線漸進(jìn)方式完成，從而避免了軟件開發(fā)不受控制的局面，使開發(fā)狀態(tài)變得有序。

SCM工具可以對(duì)同一文件的不同版本進(jìn)行差異比較，可以恢復(fù)個(gè)別文件或整個(gè)項(xiàng)目的 早期版本，使用戶方便地得到升級(jí)和維護(hù)必需的程序和文檔。

SCM工具內(nèi)部對(duì)版本的標(biāo)識(shí)，采用了版本號(hào)方式，但對(duì)用戶提供了多種途徑來標(biāo)識(shí)版 本，被廣泛應(yīng)用的有版本號(hào)、標(biāo)簽和時(shí)間戳。多樣靈活的標(biāo)識(shí)手段，為用戶提供了方便。

配置對(duì)象控制：以Webapp為例，Webapp包括很多配置對(duì)象：內(nèi)容對(duì)象、功能構(gòu)件和 接口對(duì)象。可以按任何方式來標(biāo)識(shí)Webapp對(duì)象，只要適用于組織就可以。但是，為了維護(hù) 不同平臺(tái)之間的兼容性，建議采用下面的約定：文件名長(zhǎng)度應(yīng)該不超過32個(gè)字符，避免使用大小寫昏黃的或全部大寫的名稱，也應(yīng)避免使用下劃線。另外，配置對(duì)象內(nèi)的URL地址 應(yīng)該使用相對(duì)路徑。

22.8研究某現(xiàn)有的SCM工具，并描述它實(shí)現(xiàn)版本控制的方法。此外，閱讀2-3篇有關(guān)SCM 的文章，并描述用于版本控制的不同數(shù)據(jù)結(jié)構(gòu)和引用機(jī)制。

答：SCM用如下方式實(shí)現(xiàn)版本控制：SCM工具記錄項(xiàng)目和文件的修改軌跡，跟蹤修改 信息，使軟件開發(fā)工作以基線漸進(jìn)方式完成，從而避免了軟件開發(fā)不受控制的局面，使開發(fā) 狀態(tài)變得有序。

SCM工具可以對(duì)同一文件的不同版本進(jìn)行差異比較，可以恢復(fù)個(gè)別文件或整個(gè)項(xiàng)目的 早期版本，使用戶方便地得到升級(jí)和維護(hù)必需的程序和文檔。

SCM工具內(nèi)部對(duì)版本的標(biāo)識(shí)，采用了版本號(hào)方式，但對(duì)用戶提供了多種途徑來標(biāo)識(shí)版 本，被廣泛應(yīng)用的有版本號(hào)、標(biāo)簽和時(shí)間戳。多樣靈活的標(biāo)識(shí)手段，為用戶提供了方便。

數(shù)據(jù)結(jié)構(gòu)和引用機(jī)制：文件版本的組織體現(xiàn)在版本樹結(jié)構(gòu)中，每個(gè)文件都可以通過 checkout-edit-checkin的命令形成多個(gè)版本，還可以包含多層分支和子分支。ClearCase可以 對(duì)目錄和子目錄進(jìn)行版本控制，允許開發(fā)者對(duì)其數(shù)據(jù)的組織發(fā)展過程進(jìn)行追蹤。日錄版本對(duì) 一些改變進(jìn)行控制，如建立一個(gè)新文件、修改文件名、建立新的子目錄或在目錄間移動(dòng)文件 等。同時(shí)也支持對(duì)目錄自動(dòng)進(jìn)行比較和歸并的操作。

（參考文獻(xiàn)：曹洪嵐“淺談軟件配置管理”中國(guó)會(huì)議2009.10.1

趙文杰“軟件配置管理理論與實(shí)踐”現(xiàn)代計(jì)算機(jī)（專業(yè)版）2010.12.25 ）

22.12什么是內(nèi)容管理？通過Web去研究?jī)?nèi)容管理工具的特性，并給出簡(jiǎn)要的總結(jié)。

答：在某種意義上，內(nèi)容管理和配置管理是相關(guān)的，因?yàn)閮?nèi)容管理系統(tǒng)確定了如何獲取 現(xiàn)有內(nèi)容、如何按照能夠提交給最終用戶的方式構(gòu)造現(xiàn)有內(nèi)容、然后在客戶端環(huán)境下顯示這 些內(nèi)容的過程。

內(nèi)容管理系統(tǒng)在創(chuàng)建動(dòng)態(tài)Webapp的時(shí)候最常用。動(dòng)態(tài)Webapp能夠“動(dòng)態(tài)的”創(chuàng)建 Web頁(yè)面，由用戶向Webapp請(qǐng)求特定信息，Webapp査詢數(shù)據(jù)庫(kù)并形成相應(yīng)信息，然后提交給用戶。

?

第一章?

1.1舉出至少5個(gè)例子來說明“意外效應(yīng)法則”在計(jì)算機(jī)軟件方面的應(yīng)用。?答:典型的例子包括使用“數(shù)字汽車儀表板”的軟件，賦予高科技，高品質(zhì)的圖像的軟件;如廣泛的消費(fèi)類電子產(chǎn)品的軟件;個(gè)人電腦，工業(yè)儀器儀表和機(jī)器的軟件。軟件分化出的在電子商務(wù)方面的應(yīng)用。?

1.2舉例說明軟件對(duì)社會(huì)的影響(包括正面影響和負(fù)面影響)。?

答:這是一個(gè)很好的課堂討論問題(如果時(shí)間允許)，而不是專注于老生常談的(但很重要)隱私問題，生活質(zhì)量等問題。您可能想要討論關(guān)于”技術(shù)恐懼“方面的問題，軟件也許會(huì)使它惡化但也可能減少”技術(shù)恐懼“。另一個(gè)有趣的方面是使用諾依曼的“風(fēng)險(xiǎn)”列在SEN中做重點(diǎn)討論。你也可以考慮基于軟件的“現(xiàn)金”經(jīng)濟(jì)，新模式的互動(dòng)娛樂，虛擬現(xiàn)實(shí)，電子商務(wù)等方面來思考軟件對(duì)社會(huì)的影響。?

1.3針對(duì)1.1節(jié)提出的5個(gè)問題，請(qǐng)給出你的答案，并與同學(xué)討論。?答:軟件需要如此長(zhǎng)的開發(fā)時(shí)間:?

a)設(shè)施不上線?

b)開發(fā)工具并不如預(yù)期般運(yùn)作?

c)客戶提出的新要求，需要重新設(shè)計(jì)和返工?

d)產(chǎn)品依賴于政府的規(guī)定，被意外更改。?

e)嚴(yán)格的要求，與現(xiàn)有系統(tǒng)的兼容性需要超過預(yù)期更多的測(cè)試，設(shè)計(jì)和實(shí)現(xiàn)。?f)多個(gè)操作系統(tǒng)下運(yùn)行的任務(wù)需求比預(yù)期需要更長(zhǎng)的時(shí)間。?

g)軟件項(xiàng)目風(fēng)險(xiǎn)管理比預(yù)期需要更多的時(shí)間。?

h)依賴的技術(shù)仍處于開發(fā)階段，從而延長(zhǎng)日程安排。?

開發(fā)成本高:?

a)比當(dāng)時(shí)預(yù)期低得令人無法接受的質(zhì)量，需要進(jìn)行更多的測(cè)試，設(shè)計(jì)和實(shí)施工作。?

b)制定了錯(cuò)誤的軟件功能需要重新設(shè)計(jì)和實(shí)施。?

c)開發(fā)錯(cuò)誤的用戶界面，而導(dǎo)致重新設(shè)計(jì)和實(shí)施。?

d)開發(fā)了不需要的額外的軟件功能而延長(zhǎng)了開發(fā)日程安排。?

在將軟件交付顧客使用之前，我們無法找到所有錯(cuò)誤:?

a)產(chǎn)品依賴于政府監(jiān)管，意外而改變。?

b)產(chǎn)品技術(shù)標(biāo)準(zhǔn)草案，會(huì)意外更改。?

c)有時(shí)會(huì)在項(xiàng)目后期添加新的開發(fā)人員。?

d)因?yàn)閳F(tuán)隊(duì)內(nèi)的沖突有時(shí)會(huì)導(dǎo)致溝通不暢，而產(chǎn)生糟糕的設(shè)計(jì)。?

e)破壞高效調(diào)度產(chǎn)生的項(xiàng)目管理成果和無效的規(guī)劃?

f)有時(shí)裝備部件質(zhì)量差，導(dǎo)致額外的測(cè)試，設(shè)計(jì)和集成工作和管理額外的客戶關(guān)系。?

軟件開發(fā)和維護(hù)的過程仍舊難以度量:?

a)有時(shí)該項(xiàng)目的目的是不明確。?

b)有大量的業(yè)務(wù)所涉及的風(fēng)險(xiǎn)。?

c)如果產(chǎn)品內(nèi)置沒有裝好。?

d)我們需要不斷檢討我們的工作。?

e)進(jìn)行維護(hù)檢查的時(shí)間。?

f)在整個(gè)軟件開發(fā)過程中要徹底組織項(xiàng)目團(tuán)隊(duì)。?

1.4在交付最終用戶之前，或者首個(gè)版本投入使用之后，許多應(yīng)用程序都會(huì)有頻繁的變更。為防止變更引起軟件退化，請(qǐng)?zhí)岢鲆恍┯行У慕鉀Q措施。?答:許多現(xiàn)代應(yīng)用程序在他們呈現(xiàn)給最終用戶之前和第一個(gè)版本別使用后經(jīng)常改變，以下幾個(gè)方面來阻止軟件惡化:?

a)收集所需的信息。?

b)設(shè)計(jì)師和客戶定義軟件的總體目標(biāo)。?

c)識(shí)別已知的需求。?

d)使用現(xiàn)有的程序片段后，有助于建立原型的開發(fā)人員的工作計(jì)劃快速完成。?e)只有通過合格的培訓(xùn)或經(jīng)驗(yàn)和充分揭露相關(guān)的不足，才能保持和提高我們的技術(shù)能力和讓?

f)其他人承擔(dān)技術(shù)任務(wù)?

g)文件應(yīng)該被及時(shí)制定出來，在文件中應(yīng)該有標(biāo)準(zhǔn)定義和機(jī)制建立。?h)完成某一特定階段的審查工作。?

i)每一個(gè)關(guān)鍵團(tuán)隊(duì)成員應(yīng)該配有一個(gè)后備人員?

j)檢查規(guī)避風(fēng)險(xiǎn)的步驟是否應(yīng)用正確?

k)對(duì)未來的風(fēng)險(xiǎn)分析中檢查是否有必要收集必要的信息。?

1.5思考1.1.2節(jié)中提到的7個(gè)軟件分類。請(qǐng)問能否采用一個(gè)軟件工程方法，應(yīng)用于所有的軟件分類,并就你的答案加以解釋。?

答:七個(gè)軟件分類可應(yīng)用于同樣的方法。在這不確定的今天這些“新的挑戰(zhàn)”，無疑有很大的影響(對(duì)于商務(wù)人士，軟件工程師和最終用戶來說)然而，軟件工程師可以準(zhǔn)備通過實(shí)例化一個(gè)過程，使其有足夠的靈活性和適應(yīng)性，以適應(yīng)劇烈變化的技術(shù)，這技術(shù)一定要在未來的很長(zhǎng)一段時(shí)間被商業(yè)規(guī)則所接受。?

1.6圖1-3中，將軟件工程三個(gè)層次放在了“質(zhì)量關(guān)注點(diǎn)”這層之上。這意味著在整個(gè)開發(fā)組織內(nèi)采用質(zhì)量管理活動(dòng)，如“全面質(zhì)量管理”。仔細(xì)研究，并列出全面質(zhì)量管理活動(dòng)中關(guān)鍵原則的大綱。?

答:你也許建議同學(xué)閱讀第十六章的知識(shí)來解決問題。?

1.7隨著軟件的普及，由于程序錯(cuò)誤所帶來的公眾風(fēng)險(xiǎn)已經(jīng)成為一個(gè)愈加重要的問題。設(shè)想一個(gè)真實(shí)場(chǎng)景，由于軟件錯(cuò)誤而引起“世界末日”般重大危害(危害社會(huì)經(jīng)濟(jì)或是人類生命財(cái)產(chǎn)安全)。?

答:確實(shí)有很多現(xiàn)實(shí)生活中的情況來選擇，例如，軟件錯(cuò)誤，造成了重大的電話網(wǎng)絡(luò)失敗。?

如在航空電子設(shè)備故障導(dǎo)致飛機(jī)墜毀。計(jì)算機(jī)病毒(如米開朗基羅)的攻擊給主要的電子商務(wù)網(wǎng)站造成了重大的經(jīng)濟(jì)損失。?

1.8用自己的話描述過程框架。當(dāng)我們談到框架活動(dòng)適用于所有的項(xiàng)目時(shí)，是否意味著對(duì)于不同規(guī)模和復(fù)雜度的項(xiàng)目，可應(yīng)用相同的工作任務(wù),請(qǐng)解釋。?答:過程框架適用于所有的項(xiàng)目，在相同的工作任務(wù)，適用于所有項(xiàng)目，無論其規(guī)模大小或復(fù)雜性。一個(gè)過程框架涉及大量的與客戶溝通來收集需求;這個(gè)活動(dòng)建立了一個(gè)軟件工程工作計(jì)劃。它涉及到創(chuàng)建模型，這將有助于開發(fā)人員

了解顧客的要求從而進(jìn)行設(shè)計(jì)。從而涉及構(gòu)建(代碼生成和錯(cuò)誤測(cè)試)。最后，它提供了基于評(píng)價(jià)的反饋。?

1.9普適性活動(dòng)存在于整個(gè)軟件過程中，你認(rèn)為他們均勻分布于軟件過程中，還是會(huì)集中在某個(gè)或者某些框架活動(dòng)中,?

答:傘活動(dòng)在整個(gè)軟件過程中發(fā)生，它們被均勻地應(yīng)用在整個(gè)過程中，分析還包含一系列的工作任務(wù)(例如需求收集，制定，協(xié)商規(guī)范和驗(yàn)證)，一個(gè)過程框架有一組傘被應(yīng)用在整個(gè)軟件過程活動(dòng)中。這些活動(dòng)包括:軟件項(xiàng)目跟蹤和控制，風(fēng)險(xiǎn)管理，軟件質(zhì)量保證，和正式的技術(shù)審查，測(cè)量，軟件配置管理，可重用性管理和工作產(chǎn)品的制作和生產(chǎn)。?

1.10在1.5節(jié)所列舉的神話中，增加兩種軟件神話，同時(shí)指出與其相對(duì)應(yīng)的真實(shí)情況。?

答:沒有標(biāo)準(zhǔn)答案(例如測(cè)試可以解決所有的程序錯(cuò)誤)。?

第二章?

2.1在本章的介紹中，Baetjer說過:“軟件過程為用戶和設(shè)計(jì)者之間、用戶和開發(fā)工具之間以及設(shè)計(jì)者和開發(fā)工具之間提供交互的途徑[技術(shù)]”。對(duì)于要構(gòu)建的軟件產(chǎn)品，在以下方面設(shè)計(jì)五個(gè)問題:(a)設(shè)計(jì)者應(yīng)該問用戶的問題;(b)用戶應(yīng)該問設(shè)計(jì)者的問題;(c)用戶對(duì)將要構(gòu)建的軟件自問的問題;(d)設(shè)計(jì)者對(duì)于軟件產(chǎn)品和建造該產(chǎn)品采取的軟件過程自問的問題。?

答:a)設(shè)計(jì)人員詢問用戶:?

產(chǎn)品滿意嗎或者它需要重新設(shè)計(jì)或返工嗎,?

征求用戶輸入來避免產(chǎn)品不滿意和要求返工。?

有新要求的需要嗎,?

該產(chǎn)品比估計(jì)的大嗎,?

與預(yù)期的相比模塊需要更多的測(cè)試，設(shè)計(jì)和實(shí)行工作來糾正嗎,?

b) 用戶詢問設(shè)計(jì)者的問題:?

范圍明確嗎,?

我們是否有開發(fā)工具和人員開發(fā)軟件所需的技能,?

定義的需求是正確的嗎,還有沒有額外的需要,?

特定領(lǐng)域的軟件產(chǎn)品比平時(shí)的花費(fèi)更多的時(shí)間嗎,?

該模塊是否需要更多的設(shè)計(jì)測(cè)試,?

c)用戶對(duì)將要構(gòu)建的軟件自問的問題:?

軟件產(chǎn)品的范圍和目的是什么?

該產(chǎn)品比估計(jì)的大嗎,?

有優(yōu)秀的人可用嗎,?

工作人員可靠嗎有沒有具備所需要的技能,?

能保持工作人員的離職率足夠低嗎,?

d)設(shè)計(jì)者對(duì)于軟件產(chǎn)品和建造該產(chǎn)品采取的軟件過程自問的問題:?范圍和目的文件是什么,?

要使用什么樣的工具,?

有什么目標(biāo)和規(guī)避風(fēng)險(xiǎn)的優(yōu)先事項(xiàng),?

對(duì)風(fēng)險(xiǎn)分析，識(shí)別，估計(jì)，評(píng)價(jià)和管理會(huì)有什么樣的步驟,?

2.2為溝通活動(dòng)設(shè)計(jì)一些列的動(dòng)作，選定一個(gè)動(dòng)作作為其設(shè)計(jì)一個(gè)任務(wù)集。?答:任務(wù)交流活動(dòng)設(shè)置:任務(wù)組將定義實(shí)際的工作需要，以完成一個(gè)軟件工程的行動(dòng)。這些都是對(duì)于通信的活動(dòng):?

a)利益相關(guān)者對(duì)項(xiàng)目做一個(gè)列表。?

b)邀請(qǐng)所有利益相關(guān)者的非正式會(huì)議。?

c)要求他們作出特性和功能列表。?

d)討論需求并建立一個(gè)最終的的列表。?

e)他不確定的優(yōu)先級(jí)的要求和要注意的地方。?

這些任務(wù)可能是一個(gè)復(fù)雜的軟件項(xiàng)目，然后，他們可能包括:?

a)要進(jìn)行一系列的規(guī)范會(huì)議，基于利益相關(guān)者的輸入，建立了初步的功能和特性列表。?

b)要建立一個(gè)股權(quán)持有人要求的修訂清單。?

c)使用質(zhì)量功能展開技術(shù)來滿足需求。?

d)注意在系統(tǒng)上的約束和限制。?

e)討論驗(yàn)證系統(tǒng)的方法。?

2.3在溝通過程中，遇到兩位對(duì)軟件如何做有著不同想法的利益相關(guān)者是很常見的問題。也就是說你得到了相互沖突的需求。設(shè)計(jì)一種過程模式(可以是步驟模式)，利用2.13節(jié)中針對(duì)此類問題的模板，給出一種行之有效的解決方法。?答:?

模式名:利益相關(guān)者的需求沖突。?

意圖:此模式描述的方式是解決利益相關(guān)者之間在通信框架活動(dòng)中的沖突。?類型:階段模式。?

初始背景:(1)利益相關(guān)者已確定(2)利益相關(guān)者和軟件工程師已經(jīng)建立了協(xié)作通信(3) 軟件要解決的主要問題由軟件開發(fā)團(tuán)隊(duì)已建立。(4)對(duì)已開發(fā)的項(xiàng)目范圍，基本的業(yè)務(wù)需求和項(xiàng)目的限制有了初步的了解。?

問題:對(duì)正在開發(fā)的軟件，利益相關(guān)者的需求出現(xiàn)了相互的矛盾。?解決辦法:所有的利益相關(guān)者被要求區(qū)分需求的優(yōu)先級(jí)，暫時(shí)保住利益相關(guān)者的優(yōu)先級(jí)最高或投票的最多的需求從而解決這一問題。?

結(jié)果:由利益相關(guān)方的確定的需求優(yōu)先順序列表來指導(dǎo)軟件開發(fā)團(tuán)隊(duì)構(gòu)件軟件初始模型。?

相關(guān)模式:定義指導(dǎo)和協(xié)作方針，范圍隔離，需求收集，約束描述和混合需求。?已知用途/范例:必要的溝通是貫通整個(gè)軟件工程中。?

2.4閱讀[Nog001]，然后寫一篇2-3頁(yè)的論文，討論混亂對(duì)軟件工程的影響。?答案略。?

2.5詳細(xì)描述三個(gè)適用于采用瀑布模型的軟件項(xiàng)目。?

答:適合瀑布模型的項(xiàng)目例如數(shù)據(jù)結(jié)構(gòu)，軟件架構(gòu)，程序的細(xì)節(jié)和接口表征的對(duì)象。?

2.6詳細(xì)描述三個(gè)適用于采用原型模型的軟件項(xiàng)目。?

答:相對(duì)容易的原型模型幾乎總是涉及人機(jī)交互和/或復(fù)雜計(jì)算機(jī)圖形軟件應(yīng)用

程序，有時(shí)適合原型模型是某些類別的數(shù)學(xué)算法，命令驅(qū)動(dòng)系統(tǒng)和其他應(yīng)用在沒有實(shí)時(shí)交互時(shí)結(jié)果可以很容易地檢查。難以用原型模型的應(yīng)用程序，包括控制和過程控制功能許多種類的實(shí)時(shí)應(yīng)用程序和嵌入式軟件。?

2.7如果將原型變成一個(gè)可發(fā)布的系統(tǒng)或產(chǎn)品，應(yīng)該如何調(diào)整過程,?答:如果將原型變成一個(gè)可發(fā)布的系統(tǒng)或產(chǎn)品，軟件工程師和客戶需要滿足和定義軟件的總體目標(biāo)，識(shí)別已知的任何要求，對(duì)整體輪廓進(jìn)一步的強(qiáng)制定義。原型作為一種機(jī)制，用于識(shí)別軟件需求。如果一個(gè)工作原型被建立了，開發(fā)商會(huì)試圖利用現(xiàn)有的程序片段或應(yīng)用工具(例如，報(bào)表生成器，窗口管理等)使工作方案，可以快速生成。?

2.8詳細(xì)描述三個(gè)適于采用增量模型的軟件項(xiàng)目。?

答: 每一個(gè)線性序列產(chǎn)生的“增量”交付的軟件，例如字處理軟件開發(fā)使用增量范式可能會(huì)提供基本的文件管理，編輯和文件制作功能在第一增量，更復(fù)雜的編輯和文件制作能力在第二增量;拼寫和語法檢查在第三增量，先進(jìn)的頁(yè)面布局能力在第四增量。任何增量的處理流程?

可以納入原型范式。增量發(fā)展是特別有用當(dāng)人員無法在經(jīng)營(yíng)期限為一個(gè)已成立的項(xiàng)目做完美的實(shí)施。?

2.9當(dāng)沿著螺旋過程流發(fā)展的時(shí)候，你對(duì)正在開發(fā)或者維護(hù)的軟件的看法是什么,?

答:隨著工作的螺旋向外移動(dòng)，產(chǎn)品走向一個(gè)更完整的狀態(tài)，執(zhí)行工作的抽象層次減少了。?

2.10可以合用幾種過程模型嗎,如果可以，舉例說明。?

答:過程模型可以合用，每個(gè)模型都有個(gè)有點(diǎn)不同的處理流程，但都執(zhí)行相同的通用框架活動(dòng)集:溝通，規(guī)劃，建模，施工和交付/反饋。例如線性順序模型可以作為一個(gè)有用的過程模型，在被固定的情況下，要求工作以線性的方式繼續(xù)進(jìn)行，直至完成。在這情況下，開發(fā)者可能無法確定一種算法的效率，一個(gè)操作系統(tǒng)的適應(yīng)性或應(yīng)采取的人機(jī)交互的形式。在這之中，以及許多其他場(chǎng)合原型模型可以提供最好的辦法。在其他情況下，以漸進(jìn)的方式可能是有意義的和螺旋模型的流動(dòng)可能是有效率，特殊過程模型具有許多的一個(gè)或多個(gè)傳統(tǒng)的特性。?

2.11協(xié)同過程模型定義了一套“狀態(tài)”，用你自己的話描述一下這些狀態(tài)表示什么，并指出他們?cè)趨f(xié)同過程模型中的作用。?

答:簡(jiǎn)而言之，并發(fā)進(jìn)程模型假定不同的部分項(xiàng)目會(huì)有所不同階段的完整性，因此，不同的軟件工程活動(dòng)都被同時(shí)執(zhí)行。目前的挑戰(zhàn)是管理的并發(fā)，并能夠評(píng)估該項(xiàng)目的狀態(tài)。?

2.12開發(fā)質(zhì)量“足夠好”的軟件，其優(yōu)點(diǎn)和缺點(diǎn)是什么,也就是說，當(dāng)我們追求開發(fā)速度勝過產(chǎn)品質(zhì)量的時(shí)候，會(huì)產(chǎn)生什么后果,?

答:開發(fā)質(zhì)量“足夠好”的軟件可能會(huì)碰到死亡線(截止時(shí)間)，但質(zhì)量會(huì)是比

較好的。當(dāng)追求開發(fā)速度超過了產(chǎn)品的質(zhì)量，這可能會(huì)導(dǎo)致許多缺陷，該軟件可能需要更多的測(cè)試，設(shè)計(jì)和實(shí)施工作。需求定以的不是很清楚，可能需要不斷地改變。半調(diào)子和速度過快開發(fā)都可能導(dǎo)致無法檢測(cè)到重大的項(xiàng)目風(fēng)險(xiǎn)。質(zhì)量太差可能導(dǎo)致過多的質(zhì)量問題和頻繁的返工。?

2.13詳細(xì)描述三個(gè)適于采用基于構(gòu)件模型的軟件項(xiàng)目。?

答:我會(huì)建議推遲這個(gè)問題直到“軟件過程改進(jìn)”這一章。?

2.14我們可以證明一個(gè)軟件構(gòu)件甚至整個(gè)程序的正確性，可是為什么并不是每個(gè)人都這樣做,?

答:這是可能的用數(shù)學(xué)技術(shù)來證明軟件組件，甚至整個(gè)程序的正確性。然而，對(duì)于復(fù)雜的程序，這是一個(gè)非常耗時(shí)的過程。用詳盡的測(cè)試是不可能證明任何不平凡的程序的正確性，?

2.15統(tǒng)一過程和UML是同一概念嗎,解釋你的答案。?

答:UML提供了必要的技術(shù)支持和面向?qū)ο蟮能浖こ虒?shí)踐。但它并不提供流程框架來指導(dǎo)項(xiàng)目團(tuán)隊(duì)，在他們的技術(shù)應(yīng)用中。在近幾年中，雅各布森，?Rumbaugh和Booch制定的統(tǒng)一過程中框架使用UML的面向?qū)ο蟮能浖こ獭＝裉?#xff0c;統(tǒng)一的流程和UML被廣泛應(yīng)用于各種面向?qū)ο蟮捻?xiàng)目。?

第四章?

4.1需求不斷的改變，理解需求問題是軟件工程師面臨的最困難的工作之一，因此他們更少注意需求。在某些情況下，工程師們會(huì)化繁為簡(jiǎn)。其他情況下，工程師們必須嚴(yán)格地執(zhí)行具體定義的需求。需求分析是設(shè)計(jì)和施工的橋梁,不能跳過。?

4.2你可以嘗試使用方法比如QFD(質(zhì)量功能部署)通過客戶訪談和觀察、調(diào)查以及檢查歷史數(shù)據(jù)(如問題報(bào)告)為需求收集活動(dòng)獲取原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯成需求表——稱為客戶意見表，并由客戶和利益相關(guān)者評(píng)審。接下來使用各種圖表、矩陣和評(píng)估方法抽取期望的需求并盡可能導(dǎo)出令人興奮的需求。?

4.3事實(shí)上,客戶和開發(fā)人員會(huì)有一個(gè)協(xié)商的過程，開發(fā)人員會(huì)要求客戶權(quán)衡產(chǎn)品的性能與產(chǎn)品成本、上市時(shí)間之間的關(guān)系。這個(gè)協(xié)商的目的是開發(fā)一個(gè)項(xiàng)目計(jì)劃，這個(gè)計(jì)劃在滿足客戶需求的同時(shí)又能準(zhǔn)確反映了軟件開發(fā)過程中約束(如時(shí)間、人員、預(yù)算)。不幸的是,這樣的項(xiàng)目計(jì)劃很難達(dá)成,每個(gè)客戶都有自己的觀點(diǎn)。這些觀點(diǎn)并不對(duì)其他客戶都適用，此外時(shí)間是另一個(gè)重要的約束,客戶可能沒有時(shí)間與開發(fā)人員討論需求，這使得問題更加復(fù)雜。?

4.4需求模型的目的在于描述所需的信息、功能和計(jì)算機(jī)系統(tǒng)的工作領(lǐng)域。隨著軟件工程師對(duì)系統(tǒng)了解的深入以及利益相關(guān)者越來越了解他們真正的需求，這種需求模型是不斷變化的。因此，分析模型在任何時(shí)候都是用戶需求的簡(jiǎn)介?

4.5最好的協(xié)商是爭(zhēng)取“雙贏”,這會(huì)使你成為是一位談判大師。這些初期步驟的成功實(shí)施可以達(dá)到一個(gè)雙贏的結(jié)果，這是繼續(xù)開展后續(xù)的軟件工程活動(dòng)的關(guān)鍵。?

4.6第一組上下文無關(guān)問題集主要關(guān)注的是客戶、總體目標(biāo)和利益。例如，需求工程師可能會(huì)問:?

誰是這項(xiàng)工作的最初請(qǐng)求者,?

誰將使用該解決方案,?

成功的解決方案將帶來什么樣的經(jīng)濟(jì)收益,?

對(duì)于這個(gè)解決方案你還需要其他資源嗎,?

4.7-4.9答案略。?

4.10用例圖描述了參與者所能觀察到模型圖。用例圖鼓勵(lì)系統(tǒng)的功能視圖應(yīng)該轉(zhuǎn)換為面向?qū)ο蟮囊晥D。在許多情況下，為了提供更多的相互作用，用例圖需要做更詳細(xì)的闡述。?

4.11任何有一些軟件項(xiàng)目需求工程經(jīng)驗(yàn)的人都開始注意到，在特定的應(yīng)用領(lǐng)域內(nèi)某些事情在所有的項(xiàng)目中重復(fù)發(fā)生。這些分析模式在特定應(yīng)用領(lǐng)域內(nèi)提供了一些解決方案(如類、功能、行為)，在為許多應(yīng)用項(xiàng)目建模時(shí)可以重復(fù)使用。?

4.13最好的協(xié)商是爭(zhēng)取“雙贏”的結(jié)果，即利益相關(guān)者的“贏”在于獲得滿足客戶大多數(shù)需要的系統(tǒng)或產(chǎn)品，而作為軟件團(tuán)隊(duì)一員的“贏”在于按照實(shí)際情況、在可實(shí)現(xiàn)的預(yù)算和時(shí)間期限內(nèi)完成工作。?

4.14當(dāng)需求確認(rèn)解釋了一個(gè)錯(cuò)誤時(shí)，每個(gè)需求有一個(gè)問題清單。之后會(huì)有評(píng)審小組尋找它。確認(rèn)需求的評(píng)審小組包括軟件工程師、客戶、用戶、和其他利益相關(guān)者，他們?cè)跈z查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯(cuò)誤，以及可能需要進(jìn)一步解釋澄清的地方、丟失的信息、不一致性(這是建造大型產(chǎn)品或系統(tǒng)時(shí)遇到的主要問題)、沖突的需求或是不可實(shí)現(xiàn)的(不能達(dá)到的)需求。?

第五章?

5.1有沒有可能在分析建模創(chuàng)建后立即開始編碼,解釋你的答案，然后說服反方。?答:分析模型作為領(lǐng)域?qū)ο蟮脑O(shè)計(jì)和結(jié)構(gòu)的基礎(chǔ)服務(wù)。在定義了對(duì)象和屬性后，就可以開始進(jìn)行編碼，也就知道了對(duì)象之間的關(guān)系。?

5.2 一個(gè)單憑經(jīng)驗(yàn)的分析原則是:模型“應(yīng)該關(guān)注在問題域或業(yè)務(wù)域中可見的需求”。在這些域中哪些類型的需求是不可見的,提供一些例子。?

答:正如我們所知道的，在開始階段很可能沒有完整的需求規(guī)范。客戶可能不是非常精確地確定他們的所有需求。開發(fā)者也沒有把握使用一個(gè)具體的方法來正常的完成系統(tǒng)的功能和性能。為了需求分析和建模，不傾向使用迭代的方法。分析師所將認(rèn)識(shí)到的東西進(jìn)行建模，并使用此模型作為軟件增量的設(shè)計(jì)的基礎(chǔ)。軟件增量作為流程迭代的一部分被制作出來。在這些領(lǐng)域中，需求的類型是不可見的，可能因?yàn)橐恍┕δ鼙仨氃谙到y(tǒng)中實(shí)現(xiàn)，系統(tǒng)展示的行為是什么，屬性定義的接口有哪些，應(yīng)用的約束有哪些,?

5.3 域分析的目的是什么,如何將域分析與需求模式概念相聯(lián)系,?答:域分析是持續(xù)的軟件工程活動(dòng)，不與任何的軟件項(xiàng)目相關(guān)聯(lián)。它與需求模式的概念相聯(lián)系。域分析是通過一系列活動(dòng)進(jìn)行表征的過程。這些活動(dòng)從識(shí)別域開始，以描述域中對(duì)象和類的規(guī)范為結(jié)束。?

5.4 有沒有可能不完成如圖6-3所示的4種元素就開發(fā)出一個(gè)有效的分析模型,解釋一下。?

答:如果沒有圖6.3所示的4大元素，是不可能開發(fā)出一個(gè)有效的分析模型。分析模型作為域?qū)ο蟮脑O(shè)計(jì)和建造的基礎(chǔ)。?

5.5 構(gòu)建如下系統(tǒng)中的一個(gè):?

a你所在大學(xué)基于網(wǎng)絡(luò)的課程注冊(cè)系統(tǒng)。?

b一個(gè)計(jì)算機(jī)商店的基于Web的訂單處理系統(tǒng)。?

c一個(gè)小企業(yè)的簡(jiǎn)單發(fā)票系統(tǒng)。?

d內(nèi)置于電磁灶或微波爐的互聯(lián)網(wǎng)食譜。?

選擇你感興趣的系統(tǒng)開發(fā)一套試題關(guān)系圖并說明數(shù)據(jù)對(duì)象、關(guān)系和屬性。?答:需要強(qiáng)調(diào)的是，所有的數(shù)據(jù)對(duì)象和關(guān)系一定客戶可見的。為了確認(rèn)屬性正確地反映出系統(tǒng)的需求，屬性應(yīng)該被檢查。(無固定答案)?

5.6-5.9答案略。?

5.10 什么是分析包,如何使用分析包,?

答:將分析模型的各種元素以包組的方式進(jìn)行分類，成為分析包。為了說明分析包的作用，請(qǐng)思考一下視頻游戲。作為視頻游戲的分析模型，道出了大量的類。?

第六章?

6.1 對(duì)于需求分析，結(jié)構(gòu)分析與面向?qū)ο蟛呗杂泻伪举|(zhì)區(qū)別,?

答:結(jié)構(gòu)分析，考慮把數(shù)據(jù)作為分離實(shí)體的變形的數(shù)據(jù)和過程。數(shù)據(jù)目標(biāo)是被使用它們已被定義的屬性和關(guān)系建模的。過程操作數(shù)據(jù)目標(biāo)是被使用它們?cè)谙到y(tǒng)中的數(shù)據(jù)流向建模的。面向?qū)ο蠓治?#xff0c;集中于類的定義和它們合作對(duì)用戶需求所帶來的效果的方式。?

6.2 在數(shù)據(jù)流圖中，一個(gè)箭頭表示控制流還是其他,?

答:DFD數(shù)據(jù)目標(biāo)是用有標(biāo)簽的箭頭所表示的。?

6.3 什么是“信息流連續(xù)性”,當(dāng)重新定義一個(gè)數(shù)據(jù)流時(shí)，如何應(yīng)用它,?答:數(shù)據(jù)流動(dòng)連續(xù)性意味著在同一等級(jí)中的輸入和輸出必須和它們的精確等級(jí)相同。?

6.4 在生成DFD圖時(shí)，如何使用圖形化解析,?

答:在第一次需求整合會(huì)議中，應(yīng)用工程描述中分離所有名詞和動(dòng)詞的第一步被導(dǎo)出。再文法解析中，動(dòng)詞時(shí)處理和可以被如DFD中的Bubbles描述的。名詞是DFD中的外部實(shí)體(盒子)，數(shù)據(jù)或控制目標(biāo)(箭頭)，或數(shù)據(jù)存儲(chǔ)(雙實(shí)線)。?

6.5 什么是控制規(guī)格說明,?

答:控制規(guī)格(CSPEC)以兩種不同的方式描述了系統(tǒng)的行為(在被提到的基準(zhǔn)線上)，CSPEC包括一系列行為的規(guī)格的狀態(tài)圖。它也包括程序行為表——組合的行為規(guī)格。?

6.6 PSPEC和用例是同一事物嗎,如果不是，請(qǐng)解釋區(qū)別。?

答:不是。過程規(guī)格被用于去描述所有現(xiàn)在最終精煉等級(jí)的流程模型過程(算法觀點(diǎn))。一個(gè)有用的情況描述一系列行為包括演員和系統(tǒng)(更著重于用戶可見行為而非算法)。?

6.7 表示行為建模時(shí)有兩種不同“狀態(tài)”類型，它們是什么,?

答:被動(dòng)狀態(tài)展現(xiàn)出目標(biāo)屬性的正確情況。主動(dòng)狀態(tài)指明了目標(biāo)在轉(zhuǎn)化或執(zhí)行過程中的正確情況。?

6.8 如何從狀態(tài)圖區(qū)分順序圖,它們有何相似之處,?

答:狀態(tài)圖描述了系統(tǒng)的狀態(tài)并且展現(xiàn)了事件如何影響系統(tǒng)狀態(tài)。?

順序圖指明了事件如何引起目標(biāo)的遷移。?

6.9——6.10答案略。?

第七章?

7.1是的，但是設(shè)計(jì)是隱式進(jìn)行的——通常以隨意的方式進(jìn)行的。在設(shè)計(jì)過程中，我們研究程序的表現(xiàn)形式，而非程序本身。?

7.2軟件設(shè)計(jì)的目的是運(yùn)用一系列的原則、概念和實(shí)踐導(dǎo)致高質(zhì)量體系或產(chǎn)品的發(fā)展。設(shè)計(jì)的目標(biāo)是創(chuàng)建一個(gè)可以正確地實(shí)現(xiàn)所有客戶需求并有好的用戶體驗(yàn)的軟件模型。

7.3通過開展一系列的正式技術(shù)評(píng)審來評(píng)估質(zhì)量。正式技術(shù)評(píng)審是由軟件團(tuán)隊(duì)成員召開的會(huì)議。通常，根據(jù)將要評(píng)審的設(shè)計(jì)信息的范圍，選擇2人、3人或4人參與。每個(gè)人扮演一個(gè)角色:評(píng)判組長(zhǎng)策劃會(huì)議、擬定議程并主持會(huì)議;記錄員記錄筆記以保證沒有遺漏;制作人是指其工作產(chǎn)品(例如某個(gè)軟件構(gòu)件的設(shè)計(jì))被評(píng)審的人。在技術(shù)評(píng)審會(huì)議結(jié)束后，軟件團(tuán)隊(duì)決定未來的行動(dòng)以來完成最終的產(chǎn)品。

7.4為了開發(fā)一個(gè)完整的設(shè)計(jì)模型，軟件團(tuán)隊(duì)反復(fù)地開發(fā)每個(gè)模塊的元素。每次迭代提供額外的細(xì)節(jié)并且細(xì)化。此外，設(shè)計(jì)任務(wù)應(yīng)用于一個(gè)項(xiàng)目可能不同于他們應(yīng)用其他項(xiàng)目。團(tuán)隊(duì)必須適應(yīng)一個(gè)通用的任務(wù)集去滿足產(chǎn)品，人和項(xiàng)目的需

要。質(zhì)量的評(píng)估在有被修改的錯(cuò)誤的組件級(jí)的設(shè)計(jì)任務(wù)集。任務(wù)集在章節(jié)中給出。?

7.5略?

7.6軟件體系結(jié)構(gòu)是程序組件(模塊)的結(jié)構(gòu)或組織，這些組件相互作用的方式和數(shù)據(jù)結(jié)構(gòu)被這些組件所使用。然而在更廣泛的意義上講，部件可以推廣到代表主要的系統(tǒng)元件以及它們之間的交互。?

7.7略?

7.8分離關(guān)注點(diǎn)涉及通過將其分成單獨(dú)解決的子問題解決一個(gè)復(fù)雜的問題，一個(gè)問題的不同部分是相互結(jié)合的方式，給與不同的考慮，而不是合并考慮更復(fù)雜的情況。高度耦合的問題表現(xiàn)出這一特征。然而，問題的部分繼續(xù)組合，因?yàn)樾畔⒘砍^了解一個(gè)人的能力不能無限期地進(jìn)行下去，因此，當(dāng)問題非真，模塊化可以修改，但不能消除。?

7.9在某些時(shí)間關(guān)鍵應(yīng)用程序下,可能需要單塊集成軟件。然而,如果軟件是模塊化實(shí)現(xiàn)，設(shè)計(jì)可以而且應(yīng)該實(shí)現(xiàn)的。“模塊”是內(nèi)聯(lián)編碼。?

7.10信息隱藏與耦合和內(nèi)聚概念有關(guān)，通過限制信息的可用性，只限于那些絕對(duì)需要的模塊，模塊之間的耦合在本質(zhì)上是降低了。在一般情況下，信息隔離謂詞有隔離功能，因此，各模塊凝聚力也可以改善?

7.11外部環(huán)境、編譯器和操作系統(tǒng)耦合將對(duì)軟件可移植性造成不利影響。例如,考慮一個(gè)程序,這個(gè)程序被設(shè)計(jì)用來充分利用智能終端的特殊圖形的特征。如果沒有終端的軟件被搬到一個(gè)系統(tǒng),主要設(shè)計(jì)和代碼可能需要修改。

7.12我們創(chuàng)建一個(gè)功能體系由此來提煉問題。例如，考慮到檢查寫入，我們可能這樣寫:?

Refinement 1:

Write dollar amount in words

Refinement 2:

Procedure write amount;

Validate amount is within bounds; Parse to determine each dollar unit; Generate alpha representation;

end write_amount

Refinement 3:

procedure write_amount;

do while checks remain to be printed if dollar amount > upper amount bound

then print "amount too large error

message;

else set process flag true;

End if;

determine maximum significant digit; do while (process flag true and

significant digits remain)

set for corresponded alpha phrase; divide to determine whole number value;

concatenate partial alpha string; reduce significant digit count by one; End do

print alpha string;

End do

end write_amount

細(xì)化1:

寫出大寫金額總數(shù)。

細(xì)化2:

寫出大寫金額數(shù)的程序:

驗(yàn)證金額數(shù)是否在允許范圍內(nèi);

通過解析來確定美元單位;

,用α來表示金額數(shù)，寫出來;

結(jié)束寫出大寫金額數(shù)程序

細(xì)化3:

寫出大寫金額數(shù)的程序:

檢查是否還有未打印的支票，如有進(jìn)入下面的循環(huán)

判斷支票金額數(shù)是否大于上面指定的金額數(shù)

如果大于打印“金額數(shù)太大”的錯(cuò)誤信息

否則確定過程標(biāo)志符為1。

結(jié)束判斷。

當(dāng)過程標(biāo)志符為1和有效數(shù)字存在的話，進(jìn)入下面的循環(huán):

確定最高有效位;

設(shè)置對(duì)應(yīng)阿爾法短語;

劃分來確定整數(shù)值;

連接部分α字符串;

7.13略?

7.14不，重構(gòu)是一種不改變代碼的外部行為和其功能而改善軟件產(chǎn)品的內(nèi)部質(zhì)量的過程。他可能是提高了一個(gè)函數(shù)的處理速度或者在另一個(gè)系統(tǒng)中起到簡(jiǎn)化組件的作用。?

7.15四個(gè)要素的設(shè)計(jì)模型:?

設(shè)計(jì)模型的四個(gè)元素:?

數(shù)據(jù)/類設(shè)計(jì)——建立由分析轉(zhuǎn)化的基于類內(nèi)元素的類模型和按數(shù)據(jù)結(jié)構(gòu)要求實(shí)現(xiàn)的軟件。?

結(jié)構(gòu)設(shè)計(jì)——定義大體軟件元素結(jié)構(gòu)件的關(guān)系。?

接口設(shè)計(jì)——描述軟件元素,硬件元素和用戶終端通信。?

組件等級(jí)設(shè)計(jì)——建立由軟件組件的程序描述中的軟件結(jié)構(gòu)所定義的元素結(jié)構(gòu)變形。?

第八章?

8.1用一個(gè)房屋或建筑結(jié)構(gòu)作比喻，與軟件體系結(jié)構(gòu)作對(duì)照分析。經(jīng)典建筑與軟件體系結(jié)構(gòu)的原則有什么相似之處,又有何區(qū)別,?

答:建筑與軟件在風(fēng)格與模式的概念存在于宏觀與微觀層面。例如所有的方子都有總體風(fēng)格(墻、頂、地基)。這些代表了房子的宏觀風(fēng)格。微觀上的模式(房子)可以在木材的類別、壁爐的設(shè)計(jì)以及窗戶上體現(xiàn)出來。軟件體系結(jié)構(gòu)也一樣，不同部件通過不同方法的組裝，形成了不同的系統(tǒng)。不同點(diǎn):一個(gè)比較實(shí)際，另外一個(gè)比較抽象;房屋或建筑物可變化的空間比較小，軟件體系結(jié)構(gòu)變化跨度更大一點(diǎn)?

8.2舉出2到3個(gè)例子，說明8.3.1節(jié)中提到的每一種體系結(jié)構(gòu)風(fēng)格的應(yīng)用。?答:數(shù)據(jù)中心體系結(jié)構(gòu):航空訂票系統(tǒng);圖書館目錄系統(tǒng);賓館訂閱系統(tǒng)。?數(shù)據(jù)流結(jié)構(gòu):任何工程或科學(xué)中主要功能是計(jì)算的應(yīng)用程序。?

調(diào)用和返回結(jié)構(gòu):任何I-P-O申請(qǐng)。?

面對(duì)對(duì)象的體系結(jié)構(gòu):基于GUI的應(yīng)用程序;任何面向?qū)ο蟮膽?yīng)用程序?。?分層體系結(jié)構(gòu):應(yīng)用功能必須從底層操作系統(tǒng)或網(wǎng)絡(luò)詳細(xì)信息分離的應(yīng)用程序。客戶端服務(wù)器軟件通常是分層的。?

8.3 8.3.1節(jié)中提到的一些體系結(jié)構(gòu)風(fēng)格具有層次性，而另一些則沒有。列出每種類型。沒有層次的體系風(fēng)格如何實(shí)現(xiàn),?

答:

層次:數(shù)據(jù)流，調(diào)用返回層。?

非層次:數(shù)據(jù)中心，面向?qū)ο蟆?strong>?

非分層體系結(jié)構(gòu)可能是應(yīng)用面對(duì)對(duì)象和驅(qū)動(dòng)編程技術(shù)的最好實(shí)現(xiàn)。?

8.4 在軟件體系結(jié)構(gòu)討論中，經(jīng)常會(huì)遇到體系結(jié)構(gòu)風(fēng)格、體系結(jié)構(gòu)模式及框架(本書中沒有討論)等術(shù)語。研究并描述這些術(shù)語之間的不同。?

答:許多人把建筑模式和建筑風(fēng)格等價(jià)定義(把通用系統(tǒng)模型作為程序設(shè)計(jì)的起始點(diǎn))，盡管模式往往不太廣泛。一個(gè)框架可能會(huì)被一些人定義為一組提供了一個(gè)通用的解決問題方案的類，被解決的問題可以被細(xì)化到創(chuàng)建一個(gè)應(yīng)用程序。?

8.5 選擇一個(gè)你熟悉的應(yīng)用，回答8.3.3節(jié)中對(duì)于控制與數(shù)據(jù)提出的每一個(gè)問題。?答:答案不固定。?

8.6 研究ATAM([Kaz98])并對(duì)8.5.1節(jié)提出的6個(gè)步驟進(jìn)行詳細(xì)討論。?答:答案不固定。?

8.7 如果還沒有完成習(xí)題5.6，請(qǐng)先完成它。使用本章描述的設(shè)計(jì)方法開發(fā)PHTRS的軟件體系結(jié)構(gòu)。?

答:答案不固定。?

8.8 使用數(shù)據(jù)流圖和過程說明，描述一個(gè)有清楚變換流特征的計(jì)算機(jī)系統(tǒng)。定義流邊界并使用8.6.1節(jié)描述的技術(shù)將DFD映射到軟件體系結(jié)構(gòu)中?

答:答案不固定。?

第九章?

9.1構(gòu)件級(jí)設(shè)計(jì)定義了數(shù)據(jù)結(jié)構(gòu)、算法，界面特性以及分配給每個(gè)軟件構(gòu)件的通信機(jī)制。在面向?qū)ο笳Z言中(JAVA或Smalltalk)構(gòu)件為類或?qū)ο蟆Ｔ趥鹘y(tǒng)語言(C或Fortran)中構(gòu)件式函數(shù)或操作過程。在混合語言中(如C++)構(gòu)件可能是函數(shù)或類。?

9.2像面向?qū)ο蟮臉?gòu)件一樣，傳統(tǒng)軟件構(gòu)件是由分析模型所導(dǎo)出的。然而在這種情況下，導(dǎo)出構(gòu)件是以分析模型中面向數(shù)據(jù)流元素作為基礎(chǔ)。數(shù)據(jù)流圖的最低層的每個(gè)變換都被映射為某一層上的模塊。控制構(gòu)件(模塊)位于層次結(jié)構(gòu)(體系結(jié)構(gòu))頂層附近，而問題域構(gòu)件則傾向位于層次結(jié)構(gòu)的底層。為了獲得有效的模塊化，在構(gòu)建細(xì)化的過程中采用了功能獨(dú)立性的設(shè)計(jì)概念。?

9.3OCP原則模塊(構(gòu)件)應(yīng)該對(duì)外延具有開放性，對(duì)修改具有封閉性。設(shè)計(jì)者應(yīng)該采用一種無需對(duì)結(jié)構(gòu)自身內(nèi)部(代碼或內(nèi)部邏輯)做修改就可以進(jìn)行的擴(kuò)展(在構(gòu)建所確定的功能域內(nèi))的方式來說明構(gòu)件。設(shè)計(jì)者進(jìn)行抽象，在那些需要擴(kuò)展的功能與設(shè)計(jì)類本身之間起到緩沖區(qū)作用。?

9.4依賴性倒置原則(DIP)，依賴于抽象。不依賴于具體實(shí)現(xiàn)。構(gòu)件依賴的其他具體構(gòu)件(不是依賴抽象類，如接口)越多，擴(kuò)展起來越困難。?

9.5構(gòu)件級(jí)設(shè)計(jì)中面向?qū)ο笙到y(tǒng)的上下文中，內(nèi)聚性意味著構(gòu)件或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件或者類自身有密切關(guān)系的屬性和操作。高內(nèi)聚的構(gòu)件會(huì)與其他構(gòu)件提供的服務(wù)“絕緣”，從而使其實(shí)施與維護(hù)更加容易。

9.6耦合是類之間彼此聯(lián)系程度的一種定性度量。隨著類(構(gòu)件)相互依賴越來越多，類之間的耦合程度亦會(huì)增加。低耦合的好處是構(gòu)件可以被修改但不會(huì)影響其他構(gòu)件。

9.7外部耦合發(fā)生在組件通信或與基礎(chǔ)設(shè)施組件(如。、操作系統(tǒng)功能、數(shù)據(jù)庫(kù)功能、通信功能)。雖然這種類型的耦合是必要的,它應(yīng)該是局限于一小部分系統(tǒng)組件或類。軟件必須在內(nèi)部和外部溝通。因此,耦合是一個(gè)不爭(zhēng)的事實(shí)。然而,設(shè)計(jì)師應(yīng)盡可能減少耦合和理解高耦合的影響不可避免。?

9.8略?

9.9 重構(gòu)是系統(tǒng)決策集散控制的過程，目的是讓頂層模塊執(zhí)行控制功能，而底層模塊處理所有輸入，執(zhí)行和輸出工作。逐步求精是通過連續(xù)精化過程細(xì)節(jié)層次來實(shí)現(xiàn)程序的開發(fā)。在傳統(tǒng)軟件開發(fā)中兩者是很相似的。?

9.10

WebAPP構(gòu)件定義為以下兩點(diǎn)之一:?

定義良好的聚合功能，為最終用戶處理內(nèi)容，或提供計(jì)算或數(shù)據(jù)處理?內(nèi)容和功能的聚合包，提供最終用戶所需的功能。?

9.11略?

9.12略?

9.13略?

9.14 人可以短暫記憶一小部分東西，分塊可以使評(píng)審者將相關(guān)概念組合成大的碎片或更大的分塊。那些具有分塊功能的構(gòu)件(如果構(gòu)件具有高內(nèi)聚低耦合特性)可以使評(píng)審者在設(shè)計(jì)審查時(shí)更簡(jiǎn)單的追蹤幾個(gè)構(gòu)件的相互作用而不是大量的單各類或方法。?

第十章?

10.1這道題應(yīng)該不難～許多早期交互式系統(tǒng)都有糟糕的界面。在現(xiàn)代環(huán)境下，讓你的學(xué)生們注重基于web的應(yīng)用程序界面。許多web應(yīng)用程序?yàn)榱?strong>Flash犧牲易用性。?

10.2例子如下:?

在它們引起“可撤銷的”損害之前抓住潛在的交互錯(cuò)誤。?

允許用戶自定義屏幕布局以及命令。?

利用分離菜單，以便通用功能。?

10.3例子如下:?

如果用戶有需求，在屏幕上一直顯示快捷鍵命令序列。?

當(dāng)一個(gè)web應(yīng)用程序需要密碼輸入的時(shí)候，提供“密碼提示”機(jī)制。?

10.4例子如下:?

使用一致的顏色，例如，紅色用作警示信息，藍(lán)色用作通知信息;?提供關(guān)鍵字驅(qū)動(dòng)的在線幫助。?

10.5答案略。?

10.6如果你的學(xué)生在任務(wù)分析上出了問題，老的備用I-P-O將會(huì)有效。?問:使用者輸入什么,它是怎么處理的,處理過程是如何通過界面表現(xiàn)出來的,產(chǎn)生的輸出是什么,?

10.7-10.11答案略。?

10.12當(dāng)響應(yīng)時(shí)間無法預(yù)測(cè)的時(shí)候，使用者會(huì)很不耐煩并且重復(fù)嘗試請(qǐng)求的命令或者嘗試另一個(gè)命令。在某些情況下，這會(huì)產(chǎn)生(命令的)排隊(duì)問題，并且在極端的情況下，會(huì)引起數(shù)據(jù)的丟失或者甚至是一個(gè)系統(tǒng)故障。研究表明，用戶可以容忍他們熟悉的應(yīng)用程序的響應(yīng)率50%的變化。對(duì)于那些不熟悉的應(yīng)用程序，使用者在15到30秒意外的延遲(也就是他們短期記憶的半衰期)后會(huì)很焦慮。?

10.13答案略。?

10.14如果你想要給你的學(xué)生一些工作項(xiàng)目表的范例，互聯(lián)網(wǎng)是一個(gè)很好的可用性調(diào)查表的來源(大部分都應(yīng)該有超過20道的問題，所以你的學(xué)生應(yīng)該需要優(yōu)先考慮他們的選擇)?

第十四章?

14.1用自己的話描述驗(yàn)證與確認(rèn)的區(qū)別。兩者都要用測(cè)試用例的設(shè)計(jì)方法和測(cè)試策略嗎,?

答:“驗(yàn)證”是通過嘗試在功能或性能上發(fā)現(xiàn)錯(cuò)誤來保證程序的正確性，“確認(rèn)”是保證軟件與需求相一致——這也是質(zhì)量的基本特征。?

14.2列出一些可能與獨(dú)立測(cè)試組(ITG)的創(chuàng)建相關(guān)的問題。IGT與SQA小組由相同的人員組成嗎,?

答:組建ITG(獨(dú)立測(cè)試組)最常見的問題是獲得并留住人才，除此之外，如果ITG與軟件工程小組的交流組織地不恰當(dāng)?shù)脑?#xff0c;兩組之間可能會(huì)產(chǎn)生敵意。最后，ITG有可能太晚接手項(xiàng)目，導(dǎo)致沒有時(shí)間完成一個(gè)周密測(cè)試的計(jì)劃和執(zhí)行。ITG和SQA(軟件質(zhì)量保證)小組不必是同一組人。ITG只關(guān)注測(cè)試，SQA小組則需要考慮到質(zhì)量保證相關(guān)的所有方面。?

14.3使用14.1.3節(jié)中描述的測(cè)試步驟來建立測(cè)試軟件的策略總是可行的嘛,對(duì)于嵌入式系統(tǒng)，出現(xiàn)哪些可能的復(fù)雜情況,?

答:它并不總是能夠進(jìn)行單元測(cè)試的測(cè)試環(huán)境，完成單元測(cè)試的復(fù)雜性(如復(fù)雜的驅(qū)動(dòng)和存根)可能無法證明效益。集成測(cè)試是復(fù)雜的通過單元測(cè)試的模塊合并計(jì)劃的有效性(特別是當(dāng)這些模塊滯后的時(shí)候)。在很多情況下(尤其是嵌入式系統(tǒng))軟件不能充分進(jìn)行驗(yàn)證測(cè)試硬件配置外的目標(biāo)。因此，驗(yàn)證和系統(tǒng)測(cè)試要相結(jié)合。?

14.4為什么對(duì)具有較高耦合度的模塊進(jìn)行單元測(cè)試,?

答:一個(gè)高度耦合的模塊要與其他模塊的數(shù)據(jù)和其他系統(tǒng)元素進(jìn)行交互。因此，其功能往往是依賴于這些耦合元件的操作。為了徹底的單元測(cè)試這樣一個(gè)模塊，耦合因素的功能必須以某種方式模擬。這將會(huì)是困難和費(fèi)時(shí)的。?

14.5“防錯(cuò)法”的概念是一個(gè)非常有效的方法。當(dāng)發(fā)現(xiàn)錯(cuò)誤時(shí)，他提供了內(nèi)置調(diào)試幫助:?

a.為防錯(cuò)發(fā)開發(fā)一組知道原則。?

b.討論利用這種技術(shù)的優(yōu)點(diǎn)。?

c.討論利用這種技術(shù)的缺點(diǎn)。?

答:一個(gè)單一的規(guī)則涵蓋了多種情況:所有數(shù)據(jù)在軟件接口(外部和內(nèi)部)應(yīng)當(dāng)經(jīng)過驗(yàn)證(如果可能的話)。?

優(yōu)點(diǎn):錯(cuò)誤不會(huì)―滾雪球‖——越滾越大?

缺點(diǎn):需要額外的處理時(shí)間和內(nèi)存(那通常只是一個(gè)很小的代價(jià))。?

14.6項(xiàng)目的進(jìn)度安排是如何影響集成測(cè)試的,?

答:完成模塊的可用性的影響順序和戰(zhàn)略整合。項(xiàng)目狀態(tài)必須是已知的，可以成功地實(shí)現(xiàn)整合規(guī)劃。?

14.7在所有的情況下，單元測(cè)試都是可能的或是值得做的嗎,提供實(shí)例來說明你的理由。?

答:如果一個(gè)模塊有3或4個(gè)下屬供應(yīng)數(shù)據(jù)模塊的一個(gè)有意義的評(píng)價(jià)是至關(guān)重要的，沒有―聚類‖所有的模塊作為一個(gè)單元，它可能無法進(jìn)行單元測(cè)試。?

14.8誰應(yīng)該完成確認(rèn)測(cè)試——是軟件開發(fā)人員還是軟件的使用者，說明你的理由。?

答:開發(fā)商，如果客戶驗(yàn)收測(cè)試計(jì)劃。開發(fā)人員和客戶(用戶)如果沒有進(jìn)一步的測(cè)試計(jì)劃。一個(gè)獨(dú)立的測(cè)試組可能是這里最好的選擇，但這不是一個(gè)選擇。?

14.9為本書討論的safehouse系統(tǒng)開發(fā)一個(gè)完整的測(cè)試策略，并以測(cè)試規(guī)格說明的方式形成文檔。?

答:略?

14.10作為一個(gè)班級(jí)項(xiàng)目，為你的安裝開發(fā)調(diào)試指南。這個(gè)指南應(yīng)該提供面向語言和面向系統(tǒng)的建議。這些建議是通過總結(jié)學(xué)校學(xué)習(xí)過程中所遇到的挫折得到的。從一個(gè)經(jīng)過全班和老師評(píng)審過的大綱開始，并在你局部范圍內(nèi)將這個(gè)指南發(fā)布給其他人。?

答:略?

第十五章?

15.1 Myers[mye79]用以下程序作為測(cè)試能力的自我評(píng)估:某程序讀入三個(gè)整數(shù)值表示三角形的三條邊。改程序打印信息表明三角形是不規(guī)則的，等腰的或等邊的。開發(fā)一組測(cè)試用例測(cè)試改程序。?

答:參考Myers[mye79]對(duì)此問題提出的極其詳細(xì)的―解決方案‖。?

15.2設(shè)計(jì)并實(shí)現(xiàn)15.1描述的程序(適當(dāng)使用錯(cuò)誤處理)。從該程序中導(dǎo)出流圖并用基本路徑測(cè)試方法設(shè)計(jì)測(cè)試，以保證程序中的所有語句都被測(cè)試到。執(zhí)行測(cè)試用例并顯示結(jié)果。?

答:你可以選擇發(fā)布程序源代碼給您的學(xué)生(故意地嵌入一些錯(cuò)誤)。?

15.3你能夠想出15.1.1節(jié)中沒有討論的其他測(cè)試目標(biāo)嗎,?

答:除了那些目標(biāo)之外還有:?

a) 一個(gè)成功的測(cè)試顯示功能和性能要求;?

b) 一個(gè)成功的測(cè)試發(fā)現(xiàn)文件錯(cuò)誤;?

c) 一個(gè)成功的測(cè)試發(fā)現(xiàn)接口問題;?

d) 一個(gè)成功的測(cè)試驗(yàn)證了程序結(jié)構(gòu)，了解數(shù)據(jù)結(jié)構(gòu)，界面設(shè)計(jì)和程序設(shè)計(jì);?e) 一個(gè)成功的測(cè)試，建立了一個(gè)進(jìn)入一個(gè)測(cè)試案例數(shù)據(jù)庫(kù)，以后可以用于回歸測(cè)試。?

15.4選擇一個(gè)你最近設(shè)計(jì)和實(shí)現(xiàn)的構(gòu)建。設(shè)計(jì)一組測(cè)試用例，保證利用基本路徑測(cè)試執(zhí)行所有語句。?

答:略?

15.5-15.8

答:進(jìn)行一些拓展，這些問題可以被指定為一個(gè)長(zhǎng)期的項(xiàng)目。?

15.9至少給出三個(gè)例子，在這些例子中，黑盒測(cè)試能給人“一切正常”的印象，而白盒測(cè)試可能發(fā)現(xiàn)錯(cuò)誤。再至少給出三個(gè)例子，在這些例子中白盒測(cè)試能給人“一切正常”的印象，而黑盒測(cè)試可能發(fā)現(xiàn)錯(cuò)誤。?

答:對(duì)于特定的輸入，一個(gè)內(nèi)部發(fā)生的錯(cuò)誤導(dǎo)致:?

1) 不恰當(dāng)?shù)臄?shù)據(jù)被設(shè)在一個(gè)全局?jǐn)?shù)據(jù)域里;?

2) 不恰當(dāng)?shù)臉?biāo)記將在隨后進(jìn)行的一系列測(cè)試中被測(cè)試;?

3) 不恰當(dāng)硬件控制，只可能在系統(tǒng)測(cè)試時(shí)被發(fā)現(xiàn);但是卻產(chǎn)生了正確的輸出。?

15.10不，即使窮舉測(cè)試(如果可能的話)也不能發(fā)現(xiàn)軟件說明書中的性能問題和錯(cuò)誤。在這種情況下需要同時(shí)考慮輸入和輸出的等價(jià)類。對(duì)每一個(gè)類來說，學(xué)生應(yīng)當(dāng)根據(jù)數(shù)值范圍，集合的元素，系統(tǒng)命令等劃定邊界。這可以作為筆試以及一些著名應(yīng)用GUI的測(cè)試用例的素材?

15.11生成一系列用例來幫助測(cè)試用戶的文件材料是一個(gè)好辦法。?

第十六章?

16.1用自己的話，描述為什么在面向?qū)ο笙到y(tǒng)中，類是最小的合理測(cè)試單元。?答:類封裝了數(shù)據(jù)以及處理數(shù)據(jù)的操作。由于數(shù)據(jù)和操作被打包成一個(gè)整體，一個(gè)一個(gè)地測(cè)試方法沒有作用，不能發(fā)現(xiàn)與消息傳送，職責(zé)和協(xié)作相關(guān)的錯(cuò)誤。?

16.2若現(xiàn)有類已進(jìn)行了徹底的測(cè)試，為什么我們必須對(duì)從現(xiàn)有類?實(shí)例化的子類進(jìn)行重新測(cè)試,我們可以使用為現(xiàn)有類設(shè)計(jì)的測(cè)試用例么,?

答:由于每一個(gè)子類都繼承了父類的私有屬性和操作(事實(shí)上這些私有屬性和操作會(huì)增加復(fù)雜度)，這些子類必須在他們的操作環(huán)境中重新測(cè)試。測(cè)試用例可以重復(fù)使用，但需要針對(duì)子類的私有屬性和操作進(jìn)行擴(kuò)充。?

16.3為什么―測(cè)試‖應(yīng)該從面向?qū)ο蠓治龊驮O(shè)計(jì)開始,?

答:在之后的開發(fā)過程中，面向?qū)ο蠓治龊驮O(shè)計(jì)模型提供了大量與系統(tǒng)結(jié)構(gòu)和行為相關(guān)的信息，因此，在生成代碼之前，這些模型必須經(jīng)過嚴(yán)格的審查。所有面向?qū)ο蟮哪Ｐ蛻?yīng)當(dāng)在模型的語法，語義以及語用論的上下中經(jīng)過正確性，

完整性，一致性的測(cè)試(包括技術(shù)評(píng)審)。這些評(píng)審有可能省去很多不必要的工作和修改(錯(cuò)誤越早發(fā)現(xiàn)，維護(hù)的成本越低)。?

16.4為SafeHome導(dǎo)出一組CRC索引卡片，按照16.2.2節(jié)講述的步驟確定是否存在不一致性。?

答:答案會(huì)有不同?

16.5基于線程和基于使用的集成測(cè)試策略有什么不同,簇測(cè)試如何適應(yīng),?答:基于線程的測(cè)試用來集成一系列需要對(duì)單獨(dú)一個(gè)程序輸入或事件響應(yīng)的類。基于使用的測(cè)試屬于集成測(cè)試的一種，通過測(cè)試那些很少使用服務(wù)器類的類(稱為獨(dú)立類)開始系統(tǒng)的構(gòu)造。測(cè)試完獨(dú)立類之后，測(cè)試使用獨(dú)立類的下一層類(稱為依賴類)，按照這樣的順序逐層測(cè)試依賴類直到整個(gè)系統(tǒng)構(gòu)造完成。?

16.6將隨機(jī)測(cè)試和劃分方法運(yùn)用到設(shè)計(jì)SafeHome系統(tǒng)時(shí)定義的3個(gè)類。產(chǎn)生展示操作調(diào)用序列的測(cè)試用例。?

答:答案會(huì)有不同?

16.7運(yùn)用多類測(cè)試及從SafeHome設(shè)計(jì)的行為模型中生成的測(cè)試。?

答:答案會(huì)有不同?

16.8運(yùn)用隨機(jī)測(cè)試、劃分方法、多類測(cè)試及16.5節(jié)和16.6節(jié)所描述的銀行應(yīng)用的行為模型導(dǎo)出的測(cè)試，再生成另外生成4個(gè)測(cè)試。?

答:答案會(huì)有不同?

第十八章?

18.1基于本章給出的信息和自己的經(jīng)驗(yàn)，列舉出能夠增強(qiáng)軟件工程師能力的“十條戒律”。即，列出10條指導(dǎo)原則，使得軟件人員能夠在工作中發(fā)揮其全部潛力。?

答:?

(1)你要變得更聰明。?

(2)你要注重質(zhì)量。?

(3)你要傾聽客戶。?

(4)你要了解問題?

(5)你要對(duì)一個(gè)工作過程不斷的重復(fù)。?

(6)你不可同意荒唐的時(shí)間表。?

(7)你要測(cè)量產(chǎn)品，過程和你自己。?

(8)你要制定最有效的工作方法。?

(9)你要記住，別人也會(huì)軟件工作。?

(10)你要不斷地提高。?

18.2 SEI的人員能力成熟度模型定義了培養(yǎng)優(yōu)秀軟件人員的“關(guān)鍵實(shí)踐域”。你的老師將為你指派一個(gè)關(guān)鍵實(shí)踐域，請(qǐng)你對(duì)它進(jìn)行分析和總結(jié)。?

答:略。?

18.3描述3種現(xiàn)實(shí)生活中的實(shí)際情況，其中客戶和最終用戶是相同的人。也描述3種他們是不同人的情況。?

答:相同的人:(1)一個(gè)工程師必須開發(fā)一個(gè)供個(gè)人使用的程序。(2)一個(gè)商人創(chuàng)建供個(gè)人使用的電子表格模型。(3)一個(gè)擁有迷人的手機(jī)客戶端這一新概念的企業(yè)家。?

不同的人:(1)一個(gè)通信部門的一些業(yè)務(wù)功能的服務(wù)。(2)一個(gè)軟件開發(fā)團(tuán)隊(duì)服務(wù)營(yíng)銷的需求。(3)承包商建立的客戶的規(guī)格。?

18.4高級(jí)管理者所做的決策會(huì)對(duì)軟件工程團(tuán)隊(duì)的效率產(chǎn)生重大影響。也描述3種他們是不同人的情況。?

答:在今天的環(huán)境，裁員和外包有最直接的、重大的影響。此外，“減少開支的措施”，導(dǎo)致較低的產(chǎn)品質(zhì)量;不切實(shí)際的項(xiàng)目最后期限;對(duì)用戶的需求了解失敗;或者，反過來說，對(duì)軟件工程師的工作提出警告。?

18.5溫習(xí)Weiberg的書[Wei86]，并寫出一份2-3頁(yè)的總結(jié)，說明在使用MOI模型時(shí)應(yīng)該考慮的問題。?

答案:略。?

18.6在一個(gè)信息系統(tǒng)組織中，你被指派為項(xiàng)目經(jīng)理。你的工作是開發(fā)一個(gè)應(yīng)用程序，該程序類似于你的團(tuán)隊(duì)已經(jīng)做過的項(xiàng)目，只是規(guī)模更大而且更復(fù)雜。需求已經(jīng)由用戶改寫成文檔。你會(huì)選擇哪種團(tuán)隊(duì)結(jié)構(gòu),為什么,你會(huì)選擇哪(些)種軟件過程模型,為什么,?

答:一個(gè)封閉范型方法的團(tuán)隊(duì)結(jié)構(gòu)是一種選擇。由于需求明確，這可能會(huì)要求和配置多個(gè)分區(qū)小組。規(guī)模大的項(xiàng)目緩和了利于CD團(tuán)隊(duì)的方面。由于沒有討論日程，我們假設(shè)的交貨日期是合理的。因此，有可能使用一個(gè)線性的順序過程模型。然而，迭代模型(例如，螺旋)也是一個(gè)很好的可能性。?

18.7你被指派為一個(gè)小型軟件產(chǎn)品公司的項(xiàng)目經(jīng)理。你的工作是開發(fā)一個(gè)有突破性的產(chǎn)品，該產(chǎn)品結(jié)合了虛擬現(xiàn)實(shí)的硬件和高超的軟件。因?yàn)榧彝蕵肥袌?chǎng)的競(jìng)爭(zhēng)非常激烈，完成這項(xiàng)工作的壓力很大。你會(huì)選擇哪種團(tuán)隊(duì)結(jié)構(gòu),為什么,你會(huì)選擇哪種過程模型,為什么,?

答:隨機(jī)式范型的團(tuán)隊(duì)結(jié)構(gòu)可能是唯一可行的選擇，給出了模糊的要求和工作性質(zhì)的實(shí)驗(yàn)。應(yīng)該使用原型開發(fā)方法或者一個(gè)曾量的過程模型。?

18.8你被指派為一個(gè)大型軟件產(chǎn)品公司的項(xiàng)目經(jīng)理。你的工作是管理該公司已被廣泛使用的字處理軟件的新版本的開發(fā)。由于競(jìng)爭(zhēng)激烈，已經(jīng)規(guī)定了緊迫的最后期限，并對(duì)外公布。你會(huì)選擇哪種團(tuán)隊(duì)結(jié)構(gòu),為什么,你會(huì)選擇哪些軟件過程模型,為什么,?

答:一個(gè)開放式范型團(tuán)隊(duì)結(jié)構(gòu)可能是最好的，給定的時(shí)間壓力和熟悉的工作(然而，封閉的方法范式團(tuán)隊(duì)可能也很好)。一個(gè)曾量過程模型被推動(dòng)這項(xiàng)工作性質(zhì)的最后期限所指明。?

18.9在一個(gè)為基因工程領(lǐng)域服務(wù)的公司中，你被指派為軟件項(xiàng)目經(jīng)理。你的工作是管理一個(gè)軟件新產(chǎn)品的開發(fā)，該產(chǎn)品能夠加速基因分類的速度。這項(xiàng)工作是面向研究及開發(fā)的，但其目標(biāo)是在下一年度內(nèi)生產(chǎn)出產(chǎn)品。你會(huì)選擇哪種團(tuán)隊(duì)結(jié)構(gòu),為什么,你會(huì)選擇哪些軟件過程模型,為什么,?

答:一個(gè)隨機(jī)式范型可能是最好的，是因?yàn)檫@項(xiàng)工作是實(shí)驗(yàn)性的，且有一個(gè)企業(yè)的最后期限。另一種可能性是使用一個(gè)開放式范型的團(tuán)隊(duì)結(jié)構(gòu)。一個(gè)曾量過程模型和進(jìn)化過程模型可以用于推動(dòng)給予限期的這項(xiàng)工作。?

18.10要求開發(fā)一個(gè)小型應(yīng)用軟件，它的作用是分析一所大學(xué)開設(shè)的每一門課程，并輸出課程的平均成績(jī)(針對(duì)某個(gè)學(xué)期)。寫出該問題的范圍陳述。?答:?

分?jǐn)?shù)分析應(yīng)用程序?qū)@得所有本科和研究生的學(xué)分課程的成績(jī)和在某一學(xué)期課程注冊(cè)數(shù)據(jù)庫(kù)。分?jǐn)?shù)分析應(yīng)用程序會(huì)讀每一門課程的所有等級(jí)和計(jì)算平均成績(jī)，使用的數(shù)值范圍在A = 4和其他等級(jí)分配值來作為等級(jí)值存到uc29-1文檔。本程序會(huì)打印一個(gè)報(bào)告顯示每門課的教師和平均成績(jī)。這個(gè)報(bào)告可能會(huì)按平均成績(jī)或者教師等其他類似的特征排序。本程序可能會(huì)運(yùn)行在WindowsVista操作系統(tǒng)下。?

18.11給出18.3.2節(jié)中討論的頁(yè)面布局功能的第一級(jí)功能分解。?

答:?

一個(gè)簡(jiǎn)單的分解:?

頁(yè)面布局?

定義頁(yè)面參數(shù)?

分配文本區(qū)域?

分配圖形區(qū)域?

強(qiáng)調(diào)定義(線，著色等)?

輸入/導(dǎo)入文本?

輸入/導(dǎo)入?

編輯文本?

編輯圖形?

出頁(yè)/導(dǎo)出頁(yè)面?

最終頁(yè)面布局?

第十九章?

19.1用自己的話描述過程度量和項(xiàng)目度量之間的區(qū)別。?

答:過程度量是用來對(duì)設(shè)計(jì)和建造計(jì)算機(jī)軟件的活動(dòng)進(jìn)行評(píng)估(為了在后續(xù)項(xiàng)目提高這些活動(dòng))。?

項(xiàng)目度量是用來評(píng)估軟件項(xiàng)目的狀態(tài)。?

19.2為什么有些軟件度量是“私有的”,給出3個(gè)私有度量的例子，并給出3個(gè)公有度量的例子。?

答:當(dāng)待評(píng)估的特征無法被直接測(cè)量時(shí)一種間接的的測(cè)量方法將被使用，例如,“質(zhì)量”不能被直接測(cè)量所以只能測(cè)量軟件其他的特征，軟件的很多度量工作都間接的，因?yàn)檐浖皇且粋€(gè)有形的可以用直接測(cè)量的實(shí)體。例子?

能直接度量的物體?

紙的數(shù)量?

人的數(shù)量?

不同文件的數(shù)量?

不能直接度量的物體?

可讀性(利用模糊指數(shù))?

完整性(計(jì)算你收到的‖服務(wù)臺(tái)‖問題的數(shù)量)?

可維護(hù)性?(定時(shí)改變文檔)

19.3什么是間接測(cè)量,為什么在軟件度量工作中經(jīng)常用到這類測(cè)量,?答:沒找到答案。?

19.4Grady提出了一組軟件度量規(guī)則，你能在19.1.1節(jié)所列的規(guī)則中在增加3個(gè)規(guī)則嗎,?

答:軟件度量的額外規(guī)則:?

不找完美的指標(biāo)……它不存在。?

保證測(cè)量的一致性，避免比較不同的事物。?

注重質(zhì)量，這是最重要的。?

19.5產(chǎn)品交付之前，團(tuán)隊(duì)A在軟件工程過程中發(fā)現(xiàn)了342個(gè)錯(cuò)誤，團(tuán)隊(duì)B發(fā)現(xiàn)了184個(gè)錯(cuò)誤。對(duì)于項(xiàng)目A和B，還需要做什么額外的測(cè)量，才能確定哪個(gè)團(tuán)隊(duì)能夠更有效地排除錯(cuò)誤,你建議采用什么度量能有助于做出判定,那些歷史數(shù)據(jù)可能有用,?

答:兩個(gè)團(tuán)隊(duì)?wèi)?yīng)該事先決定好要開發(fā)的軟件的大小和功能，例如，errors/FP可以提供一個(gè)規(guī)范化的評(píng)估方法。此外，在兩個(gè)團(tuán)隊(duì)的軟件開發(fā)過程中一個(gè)度量標(biāo)準(zhǔn)例如DRE可以提供一個(gè)對(duì)SQA的效率指標(biāo)。?

19.6給出反對(duì)將代碼行作為軟件生產(chǎn)率度量的論據(jù)。當(dāng)考慮幾十個(gè)或幾百個(gè)項(xiàng)目時(shí)，你說的情況還成立嗎,?

答:LOC的作用不大是因?yàn)樗莫?jiǎng)勵(lì)―verbose‖計(jì)劃，同時(shí)他也很難用在可視化編程中，4GLs，代碼生成器，或其他的代碼生成器4gts的發(fā)展正在遠(yuǎn)離3gls

19.7根據(jù)下面的信息域特性，計(jì)算項(xiàng)目的功能點(diǎn)值:?

用戶人數(shù):32

用戶輸出數(shù):60

用戶查詢數(shù):24

文件數(shù):8

外部接口數(shù):2

假定所有的復(fù)雜度校正值都取“中等”值。使用第十三章描述的算法。?答:?

總計(jì):32*4+60*5+24*4+8*10+2*7=618 FP=618*[0.65+0.01*3*14]=661

19.8利用19.2.3節(jié)中給出的表格，基于每行代碼具有的功能性，提出一個(gè)反對(duì)使用匯編語言的論據(jù)。再參考該表，討論為什么C++比C更好,?

答:用匯編語言實(shí)現(xiàn)一個(gè)功能點(diǎn)需要的行數(shù)在91到694之間平均337行，這幾項(xiàng)在表中都是最大的，一些行業(yè)分析師稱:每天無論使用任何語言的程序員都交出相同數(shù)量的調(diào)試代碼，如果開發(fā)一個(gè)項(xiàng)目真用了匯編語言那將比用其它語言花費(fèi)更多的時(shí)間，以上比較方法可以用到C與C++得比較。?

19.9用于控制影印機(jī)的軟件需要32000行C語言代碼和4200行Smalltalk語言代碼。估算該影印機(jī)軟件的功能點(diǎn)數(shù)。?

答:?

用C語言?= 162 LOC/FP

用Smalltalk = 26 LOC/FP

所以?32,000/162 + 4,200/26 = 197.53 + 161.54 = 359 FP (近似值)

19.10在一個(gè)項(xiàng)目結(jié)束時(shí)，確定在建模活動(dòng)中發(fā)現(xiàn)了30個(gè)錯(cuò)誤，在構(gòu)造活動(dòng)中發(fā)現(xiàn)了12個(gè)可以追溯到建模活動(dòng)中沒有發(fā)現(xiàn)的錯(cuò)誤。那么，建模活動(dòng)的DRE是多少,?

答:DRE = E / (E + D) = 30 / (30 + 12) = 30 / 42 = 0.71.(近似值)

19.11軟件團(tuán)隊(duì)將軟件增量交付給最終用戶。在第一個(gè)月的使用中，用戶發(fā)現(xiàn)了8個(gè)缺陷。在交付之前，軟件團(tuán)隊(duì)在正式技術(shù)評(píng)審和所有測(cè)試任務(wù)中發(fā)現(xiàn)了242個(gè)錯(cuò)誤。那么在使用一個(gè)月之后，項(xiàng)目總的缺陷排除效率(DRE)是多少,?答:DRE = E / (E + D) = 242 / (242 + 8) = 242 / 250 = 0.97(近似值)

第二十章?

20.1假設(shè)你是一家開發(fā)家用機(jī)器人軟件公司的項(xiàng)目經(jīng)理，你已經(jīng)承接了為草坪割草機(jī)器人開發(fā)軟件的項(xiàng)目。寫一個(gè)范圍陳述來描述該軟件，確定你的范圍陳述是“界定的”。如果你對(duì)機(jī)器人不熟悉，在你開始寫作之前先做一些調(diào)研工作。還要說明你對(duì)所需硬件的設(shè)想。或者，你也可以選擇其他感興趣的問題，而不做草坪割草機(jī)器人。?

答:略?

20.2在20.1節(jié)簡(jiǎn)要討論了軟件項(xiàng)目的復(fù)雜性。列出影響項(xiàng)目復(fù)雜性的軟件特性(例如，并發(fā)操作、圖形輸出)，按其對(duì)項(xiàng)目的影響程度順次排列。?答:有時(shí)，復(fù)雜性來源于客戶和軟件開發(fā)人員之間建立的一個(gè)糟糕的接口，以此，以下性能應(yīng)該被考慮?

實(shí)時(shí)屬性;

多處理要求(并發(fā));

算法的本質(zhì);

遞歸的需求;

輸入的本質(zhì);

確定性的輸入;

輸出的本質(zhì);

語言特點(diǎn);

知識(shí)/經(jīng)驗(yàn)人員的使用。

20.3在計(jì)劃過程中，性能是一個(gè)重要的考慮因素。針對(duì)不同的軟件應(yīng)用領(lǐng)域，分別討論如何以不同的方式來解釋性能。?

答:實(shí)時(shí)操作--處理原始數(shù)據(jù)的CPU時(shí)間和可能產(chǎn)生中斷服務(wù)的效率

工程/科學(xué)的應(yīng)用--數(shù)值精度和大型系統(tǒng),CPU時(shí)間。

商業(yè)的應(yīng)用--I/ O效率

交互式的應(yīng)用--用戶“等待時(shí)間”

微處理器的應(yīng)用--cpu時(shí)間和內(nèi)存需要。?

20.4對(duì)你在習(xí)題20.1中描述的機(jī)器人軟件進(jìn)行功能分解。估算每個(gè)功能的規(guī)模(用LOC)。假定你所在組織的平均生產(chǎn)率是450LOC/pm，勞動(dòng)力價(jià)格是每人月7000美元，使用本章所講的基于LOC的估算技術(shù)來估算構(gòu)造該軟件所需的工作量及成本。?

答:用戶交互(2400)

傳感器監(jiān)測(cè)(1100)

信息顯示(850)

系統(tǒng)配置(1200)

系統(tǒng)控制(激活/失活)(900)

括號(hào)中指出了對(duì)每一項(xiàng)的LOC估計(jì)，通過估計(jì)一共是6450LOC 把數(shù)據(jù)用

與這個(gè)問題6450 LOC / 450 LOC/pm = 14.3 pm

花費(fèi):?14.3 pm * $7,000/pm = $100,000 (估計(jì)值)

20.5使用COCOMOⅡ模型來估算構(gòu)造一個(gè)簡(jiǎn)單的ATM軟件所需的工作量，它產(chǎn)生12個(gè)屏幕、10個(gè)報(bào)表、將需要大約80個(gè)軟件構(gòu)件。假定該軟件具有平均復(fù)雜度和平均開發(fā)者/環(huán)境成熟度。要求使用基于對(duì)象點(diǎn)的應(yīng)用組裝模型。?答:object point = 12 * 2 + 10 * 5 + 80 * 10 = 874

我們假設(shè)?80% reuse

NOP = (object points) * [(100 - %reuse)/100]

= (874) * [(100 – 80)/100] = 874 * 0.2 = 174.8

參考p362的圖可知:?

PROD = 13

工作量?= NOP/PROD = 174.8 / 13 = 13.45

20.6使用“軟件方程”來估算草坪割草機(jī)器人軟件。假設(shè)采用方程(20-4)，p=8000。?答:假設(shè)?B=0.16 and P = 8,000

t.min = 8.14 * (LOC / P)^0.43?=

= 8.14 * (6450/8000) ^0.43?

t = t.min / 12 months/year

E = 180 * B * t^3

20.7比較習(xí)題20.4和習(xí)題20.6中所得到的工作量估算值，求出標(biāo)準(zhǔn)偏差，它如何影響你對(duì)估算的確信程度,?

答案和題目不一樣。?

20.8使用習(xí)題20.7中得到的結(jié)果，確定能否期望該軟件在6個(gè)月內(nèi)完成，以及完成該工作需要多少人員,?

答:軟件方程預(yù)測(cè)“不”但我們可能超出其邊界，使用原始的COCOMO模型。?

D = 2.5 E ^ 0.35

= 2.5 * 16.92 ^ 0.35

= 6.7人月?

看來，?6月是積極的，但有可能給出(相當(dāng)于3人工作項(xiàng)目)COCOMO的結(jié)果和項(xiàng)目的規(guī)模/復(fù)雜性。?

20.9建立一個(gè)電子表格模型，實(shí)現(xiàn)本章所述的一種或多種估算技術(shù)。或者從基于Web的資源獲取一個(gè)或多在線估算模型。?

答:略。?

20.10組建一個(gè)項(xiàng)目團(tuán)隊(duì)，開發(fā)軟件工具來實(shí)現(xiàn)本章所介紹的每種估算技術(shù)。?答:略。?

20.11有一點(diǎn)似乎很奇怪:成本和進(jìn)度估算是在軟件項(xiàng)目計(jì)劃期間完成的——在詳細(xì)的軟件需求分析或設(shè)計(jì)之前進(jìn)行。你認(rèn)為為什么會(huì)這樣,是否存在不需要這樣做的情況,?

答:很早對(duì)成本和進(jìn)度的估計(jì)是因?yàn)楣芾韺酉ＭM可能早的得到這些數(shù)據(jù)，如果這個(gè)項(xiàng)目有非常復(fù)雜的高級(jí)技術(shù)風(fēng)險(xiǎn)，所以一個(gè)固定價(jià)格的提議提交需要，項(xiàng)目的成本核算應(yīng)該(如果可能)被推遲到需求分析之后，注意:只有需求的成本是可以盡早估計(jì)。

?

總結(jié)

以上是生活随笔為你收集整理的软件工程 实践者的研究方法 中文题答案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。