軟件工程課后習(xí)題答案

1、精選優(yōu)質(zhì)文檔-傾情為你奉上第一章1.1舉出至少5個例子來說明“意外效應(yīng)法則”在計(jì)算機(jī)軟件方面的應(yīng)用。答：典型的例子包括使用“數(shù)字汽車儀表板”的軟件，賦予高科技，高品質(zhì)的圖像的軟件；如廣泛的消費(fèi)類電子產(chǎn)品的軟件；個人電腦，工業(yè)儀器儀表和機(jī)器的軟件。軟件分化出的在電子商務(wù)方面的應(yīng)用。1.2舉例說明軟件對社會的影響（包括正面影響和負(fù)面影響）。答：這是一個很好的課堂討論問題（如果時間允許），而不是專注于老生常談的（但很重要）隱私問題，生活質(zhì)量等問題。您可能想要討論關(guān)于”技術(shù)恐懼“方面的問題，軟件也許會使它惡化但也可能減少”技術(shù)恐懼“。另一個有趣的方面是使用諾依曼的“風(fēng)險(xiǎn)”列在SEN中做重點(diǎn)討論。你也可

2、以考慮基于軟件的“現(xiàn)金”經(jīng)濟(jì)，新模式的互動娛樂，虛擬現(xiàn)實(shí)，電子商務(wù)等方面來思考軟件對社會的影響。1.3針對1.1節(jié)提出的5個問題，請給出你的答案，并與同學(xué)討論。答：軟件需要如此長的開發(fā)時間：a）設(shè)施不上線b）開發(fā)工具并不如預(yù)期般運(yùn)作c）客戶提出的新要求，需要重新設(shè)計(jì)和返工d）產(chǎn)品依賴于政府的規(guī)定，被意外更改。e）嚴(yán)格的要求，與現(xiàn)有系統(tǒng)的兼容性需要超過預(yù)期更多的測試，設(shè)計(jì)和實(shí)現(xiàn)。f）多個操作系統(tǒng)下運(yùn)行的任務(wù)需求比預(yù)期需要更長的時間。g）軟件項(xiàng)目風(fēng)險(xiǎn)管理比預(yù)期需要更多的時間。h）依賴的技術(shù)仍處于開發(fā)階段，從而延長日程安排。開發(fā)成本高：a）比當(dāng)時預(yù)期低得令人無法接受的質(zhì)量，需要進(jìn)行更多的測試，設(shè)計(jì)和

3、實(shí)施工作。b）制定了錯誤的軟件功能需要重新設(shè)計(jì)和實(shí)施。c）開發(fā)錯誤的用戶界面，而導(dǎo)致重新設(shè)計(jì)和實(shí)施。d）開發(fā)了不需要的額外的軟件功能而延長了開發(fā)日程安排。在將軟件交付顧客使用之前，我們無法找到所有錯誤：a）產(chǎn)品依賴于政府監(jiān)管，意外而改變。b）產(chǎn)品技術(shù)標(biāo)準(zhǔn)草案，會意外更改。c）有時會在項(xiàng)目后期添加新的開發(fā)人員。d）因?yàn)閳F(tuán)隊(duì)內(nèi)的沖突有時會導(dǎo)致溝通不暢，而產(chǎn)生糟糕的設(shè)計(jì)。e）破壞高效調(diào)度產(chǎn)生的項(xiàng)目管理成果和無效的規(guī)劃f）有時裝備部件質(zhì)量差，導(dǎo)致額外的測試，設(shè)計(jì)和集成工作和管理額外的客戶關(guān)系。軟件開發(fā)和維護(hù)的過程仍舊難以度量：a）有時該項(xiàng)目的目的是不明確。b）有大量的業(yè)務(wù)所涉及的風(fēng)險(xiǎn)。c）如果產(chǎn)品內(nèi)置

4、沒有裝好。d）我們需要不斷檢討我們的工作。e）進(jìn)行維護(hù)檢查的時間。f）在整個軟件開發(fā)過程中要徹底組織項(xiàng)目團(tuán)隊(duì)。1.4在交付最終用戶之前，或者首個版本投入使用之后，許多應(yīng)用程序都會有頻繁的變更。為防止變更引起軟件退化，請?zhí)岢鲆恍┯行У慕鉀Q措施。答：許多現(xiàn)代應(yīng)用程序在他們呈現(xiàn)給最終用戶之前和第一個版本別使用后經(jīng)常改變，以下幾個方面來阻止軟件惡化：a)收集所需的信息。b)設(shè)計(jì)師和客戶定義軟件的總體目標(biāo)。c)識別已知的需求。d)使用現(xiàn)有的程序片段后，有助于建立原型的開發(fā)人員的工作計(jì)劃快速完成。e)只有通過合格的培訓(xùn)或經(jīng)驗(yàn)和充分揭露相關(guān)的不足，才能保持和提高我們的技術(shù)能力和讓f)其他人承擔(dān)技術(shù)任務(wù)g)文

5、件應(yīng)該被及時制定出來，在文件中應(yīng)該有標(biāo)準(zhǔn)定義和機(jī)制建立。h)完成某一特定階段的審查工作。i)每一個關(guān)鍵團(tuán)隊(duì)成員應(yīng)該配有一個后備人員j)檢查規(guī)避風(fēng)險(xiǎn)的步驟是否應(yīng)用正確k)對未來的風(fēng)險(xiǎn)分析中檢查是否有必要收集必要的信息。1.5思考1.1.2節(jié)中提到的7個軟件分類。請問能否采用一個軟件工程方法，應(yīng)用于所有的軟件分類？并就你的答案加以解釋。答：七個軟件分類可應(yīng)用于同樣的方法。在這不確定的今天這些“新的挑戰(zhàn)”，無疑有很大的影響（對于商務(wù)人士，軟件工程師和最終用戶來說）然而，軟件工程師可以準(zhǔn)備通過實(shí)例化一個過程，使其有足夠的靈活性和適應(yīng)性，以適應(yīng)劇烈變化的技術(shù)，這技術(shù)一定要在未來的很長一段時間被商業(yè)規(guī)則所

6、接受。1.6圖1-3中，將軟件工程三個層次放在了“質(zhì)量關(guān)注點(diǎn)”這層之上。這意味著在整個開發(fā)組織內(nèi)采用質(zhì)量管理活動，如“全面質(zhì)量管理”。仔細(xì)研究，并列出全面質(zhì)量管理活動中關(guān)鍵原則的大綱。答：你也許建議同學(xué)閱讀第十六章的知識來解決問題。1.7隨著軟件的普及，由于程序錯誤所帶來的公眾風(fēng)險(xiǎn)已經(jīng)成為一個愈加重要的問題。設(shè)想一個真實(shí)場景，由于軟件錯誤而引起“世界末日”般重大危害（危害社會經(jīng)濟(jì)或是人類生命財(cái)產(chǎn)安全）。答：確實(shí)有很多現(xiàn)實(shí)生活中的情況來選擇，例如，軟件錯誤，造成了重大的電話網(wǎng)絡(luò)失敗。如在航空電子設(shè)備故障導(dǎo)致飛機(jī)墜毀。計(jì)算機(jī)病毒（如米開朗基羅）的攻擊給主要的電子商務(wù)網(wǎng)站造成了重大的經(jīng)濟(jì)損失。1.8

7、用自己的話描述過程框架。當(dāng)我們談到框架活動適用于所有的項(xiàng)目時，是否意味著對于不同規(guī)模和復(fù)雜度的項(xiàng)目，可應(yīng)用相同的工作任務(wù)？請解釋。答：過程框架適用于所有的項(xiàng)目，在相同的工作任務(wù)，適用于所有項(xiàng)目，無論其規(guī)模大小或復(fù)雜性。一個過程框架涉及大量的與客戶溝通來收集需求；這個活動建立了一個軟件工程工作計(jì)劃。它涉及到創(chuàng)建模型，這將有助于開發(fā)人員了解顧客的要求從而進(jìn)行設(shè)計(jì)。從而涉及構(gòu)建（代碼生成和錯誤測試）。最后，它提供了基于評價的反饋。1.9普適性活動存在于整個軟件過程中，你認(rèn)為他們均勻分布于軟件過程中，還是會集中在某個或者某些框架活動中？答：傘活動在整個軟件過程中發(fā)生，它們被均勻地應(yīng)用在整個過程中，分析

8、還包含一系列的工作任務(wù)（例如需求收集，制定，協(xié)商規(guī)范和驗(yàn)證），一個過程框架有一組傘被應(yīng)用在整個軟件過程活動中。這些活動包括：軟件項(xiàng)目跟蹤和控制，風(fēng)險(xiǎn)管理，軟件質(zhì)量保證，和正式的技術(shù)審查，測量，軟件配置管理，可重用性管理和工作產(chǎn)品的制作和生產(chǎn)。1.10在1.5節(jié)所列舉的神話中，增加兩種軟件神話，同時指出與其相對應(yīng)的真實(shí)情況。答：沒有標(biāo)準(zhǔn)答案（例如測試可以解決所有的程序錯誤）。第二章2.1在本章的介紹中，Baetjer說過：“軟件過程為用戶和設(shè)計(jì)者之間、用戶和開發(fā)工具之間以及設(shè)計(jì)者和開發(fā)工具之間提供交互的途徑技術(shù)”。對于要構(gòu)建的軟件產(chǎn)品，在以下方面設(shè)計(jì)五個問題：（a）設(shè)計(jì)者應(yīng)該問用戶的問題；（b）

9、用戶應(yīng)該問設(shè)計(jì)者的問題；（c）用戶對將要構(gòu)建的軟件自問的問題；（d）設(shè)計(jì)者對于軟件產(chǎn)品和建造該產(chǎn)品采取的軟件過程自問的問題。答：a）設(shè)計(jì)人員詢問用戶：產(chǎn)品滿意嗎或者它需要重新設(shè)計(jì)或返工嗎？征求用戶輸入來避免產(chǎn)品不滿意和要求返工。有新要求的需要嗎？該產(chǎn)品比估計(jì)的大嗎？與預(yù)期的相比模塊需要更多的測試，設(shè)計(jì)和實(shí)行工作來糾正嗎？b) 用戶詢問設(shè)計(jì)者的問題：范圍明確嗎？我們是否有開發(fā)工具和人員開發(fā)軟件所需的技能？定義的需求是正確的嗎？還有沒有額外的需要？特定領(lǐng)域的軟件產(chǎn)品比平時的花費(fèi)更多的時間嗎？該模塊是否需要更多的設(shè)計(jì)測試？c）用戶對將要構(gòu)建的軟件自問的問題：軟件產(chǎn)品的范圍和目的是什么?該產(chǎn)品比估計(jì)的

10、大嗎？有優(yōu)秀的人可用嗎？工作人員可靠嗎有沒有具備所需要的技能？能保持工作人員的離職率足夠低嗎？d）設(shè)計(jì)者對于軟件產(chǎn)品和建造該產(chǎn)品采取的軟件過程自問的問題：范圍和目的文件是什么？要使用什么樣的工具？有什么目標(biāo)和規(guī)避風(fēng)險(xiǎn)的優(yōu)先事項(xiàng)？對風(fēng)險(xiǎn)分析，識別，估計(jì)，評價和管理會有什么樣的步驟？2.2為溝通活動設(shè)計(jì)一些列的動作，選定一個動作作為其設(shè)計(jì)一個任務(wù)集。答：任務(wù)交流活動設(shè)置：任務(wù)組將定義實(shí)際的工作需要，以完成一個軟件工程的行動。這些都是對于通信的活動：a）利益相關(guān)者對項(xiàng)目做一個列表。b）邀請所有利益相關(guān)者的非正式會議。c）要求他們作出特性和功能列表。d）討論需求并建立一個最終的的列表。e）他不確定的優(yōu)

11、先級的要求和要注意的地方。這些任務(wù)可能是一個復(fù)雜的軟件項(xiàng)目，然后，他們可能包括：a)要進(jìn)行一系列的規(guī)范會議，基于利益相關(guān)者的輸入，建立了初步的功能和特性列表。b)要建立一個股權(quán)持有人要求的修訂清單。c)使用質(zhì)量功能展開技術(shù)來滿足需求。d)注意在系統(tǒng)上的約束和限制。e)討論驗(yàn)證系統(tǒng)的方法。2.3在溝通過程中，遇到兩位對軟件如何做有著不同想法的利益相關(guān)者是很常見的問題。也就是說你得到了相互沖突的需求。設(shè)計(jì)一種過程模式（可以是步驟模式），利用2.13節(jié)中針對此類問題的模板，給出一種行之有效的解決方法。答：模式名：利益相關(guān)者的需求沖突。意圖：此模式描述的方式是解決利益相關(guān)者之間在通信框架活動中的沖突。

12、類型：階段模式。初始背景：(1)利益相關(guān)者已確定(2)利益相關(guān)者和軟件工程師已經(jīng)建立了協(xié)作通信(3) 軟件要解決的主要問題由軟件開發(fā)團(tuán)隊(duì)已建立。(4)對已開發(fā)的項(xiàng)目范圍，基本的業(yè)務(wù)需求和項(xiàng)目的限制有了初步的了解。問題：對正在開發(fā)的軟件，利益相關(guān)者的需求出現(xiàn)了相互的矛盾。解決辦法：所有的利益相關(guān)者被要求區(qū)分需求的優(yōu)先級，暫時保住利益相關(guān)者的優(yōu)先級最高或投票的最多的需求從而解決這一問題。結(jié)果：由利益相關(guān)方的確定的需求優(yōu)先順序列表來指導(dǎo)軟件開發(fā)團(tuán)隊(duì)構(gòu)件軟件初始模型。相關(guān)模式：定義指導(dǎo)和協(xié)作方針，范圍隔離，需求收集，約束描述和混合需求。已知用途/范例：必要的溝通是貫通整個軟件工程中。2.4閱讀Nog0

13、01，然后寫一篇2-3頁的論文，討論混亂對軟件工程的影響。答案略。2.5詳細(xì)描述三個適用于采用瀑布模型的軟件項(xiàng)目。答：適合瀑布模型的項(xiàng)目例如數(shù)據(jù)結(jié)構(gòu)，軟件架構(gòu)，程序的細(xì)節(jié)和接口表征的對象。2.6詳細(xì)描述三個適用于采用原型模型的軟件項(xiàng)目。答：相對容易的原型模型幾乎總是涉及人機(jī)交互和/或復(fù)雜計(jì)算機(jī)圖形軟件應(yīng)用程序，有時適合原型模型是某些類別的數(shù)學(xué)算法，命令驅(qū)動系統(tǒng)和其他應(yīng)用在沒有實(shí)時交互時結(jié)果可以很容易地檢查。難以用原型模型的應(yīng)用程序，包括控制和過程控制功能許多種類的實(shí)時應(yīng)用程序和嵌入式軟件。2.7如果將原型變成一個可發(fā)布的系統(tǒng)或產(chǎn)品，應(yīng)該如何調(diào)整過程？答：如果將原型變成一個可發(fā)布的系統(tǒng)或產(chǎn)品，軟

14、件工程師和客戶需要滿足和定義軟件的總體目標(biāo)，識別已知的任何要求，對整體輪廓進(jìn)一步的強(qiáng)制定義。原型作為一種機(jī)制，用于識別軟件需求。如果一個工作原型被建立了，開發(fā)商會試圖利用現(xiàn)有的程序片段或應(yīng)用工具（例如，報(bào)表生成器，窗口管理等）使工作方案，可以快速生成。2.8詳細(xì)描述三個適于采用增量模型的軟件項(xiàng)目。答: 每一個線性序列產(chǎn)生的“增量”交付的軟件，例如字處理軟件開發(fā)使用增量范式可能會提供基本的文件管理，編輯和文件制作功能在第一增量，更復(fù)雜的編輯和文件制作能力在第二增量；拼寫和語法檢查在第三增量，先進(jìn)的頁面布局能力在第四增量。任何增量的處理流程可以納入原型范式。增量發(fā)展是特別有用當(dāng)人員無法在經(jīng)營期限為

15、一個已成立的項(xiàng)目做完美的實(shí)施。2.9當(dāng)沿著螺旋過程流發(fā)展的時候，你對正在開發(fā)或者維護(hù)的軟件的看法是什么？答：隨著工作的螺旋向外移動，產(chǎn)品走向一個更完整的狀態(tài)，執(zhí)行工作的抽象層次減少了。2.10可以合用幾種過程模型嗎？如果可以，舉例說明。答：過程模型可以合用，每個模型都有個有點(diǎn)不同的處理流程，但都執(zhí)行相同的通用框架活動集：溝通，規(guī)劃，建模，施工和交付/反饋。例如線性順序模型可以作為一個有用的過程模型，在被固定的情況下，要求工作以線性的方式繼續(xù)進(jìn)行，直至完成。在這情況下，開發(fā)者可能無法確定一種算法的效率，一個操作系統(tǒng)的適應(yīng)性或應(yīng)采取的人機(jī)交互的形式。在這之中，以及許多其他場合原型模型可以提供最好的

16、辦法。在其他情況下，以漸進(jìn)的方式可能是有意義的和螺旋模型的流動可能是有效率，特殊過程模型具有許多的一個或多個傳統(tǒng)的特性。2.11協(xié)同過程模型定義了一套“狀態(tài)”，用你自己的話描述一下這些狀態(tài)表示什么，并指出他們在協(xié)同過程模型中的作用。答：簡而言之，并發(fā)進(jìn)程模型假定不同的部分項(xiàng)目會有所不同階段的完整性，因此，不同的軟件工程活動都被同時執(zhí)行。目前的挑戰(zhàn)是管理的并發(fā)，并能夠評估該項(xiàng)目的狀態(tài)。2.12開發(fā)質(zhì)量“足夠好”的軟件，其優(yōu)點(diǎn)和缺點(diǎn)是什么？也就是說，當(dāng)我們追求開發(fā)速度勝過產(chǎn)品質(zhì)量的時候，會產(chǎn)生什么后果？答：開發(fā)質(zhì)量“足夠好”的軟件可能會碰到死亡線（截止時間），但質(zhì)量會是比較好的。當(dāng)追求開發(fā)速度超過

17、了產(chǎn)品的質(zhì)量，這可能會導(dǎo)致許多缺陷，該軟件可能需要更多的測試，設(shè)計(jì)和實(shí)施工作。需求定以的不是很清楚，可能需要不斷地改變。半調(diào)子和速度過快開發(fā)都可能導(dǎo)致無法檢測到重大的項(xiàng)目風(fēng)險(xiǎn)。質(zhì)量太差可能導(dǎo)致過多的質(zhì)量問題和頻繁的返工。2.13詳細(xì)描述三個適于采用基于構(gòu)件模型的軟件項(xiàng)目。答：我會建議推遲這個問題直到“軟件過程改進(jìn)”這一章。2.14我們可以證明一個軟件構(gòu)件甚至整個程序的正確性，可是為什么并不是每個人都這樣做？答：這是可能的用數(shù)學(xué)技術(shù)來證明軟件組件，甚至整個程序的正確性。然而，對于復(fù)雜的程序，這是一個非常耗時的過程。用詳盡的測試是不可能證明任何不平凡的程序的正確性，2.15統(tǒng)一過程和UML是同一概

18、念嗎？解釋你的答案。答：UML提供了必要的技術(shù)支持和面向?qū)ο蟮能浖こ虒?shí)踐。但它并不提供流程框架來指導(dǎo)項(xiàng)目團(tuán)隊(duì)，在他們的技術(shù)應(yīng)用中。在近幾年中，雅各布森， Rumbaugh和Booch制定的統(tǒng)一過程中框架使用UML的面向?qū)ο蟮能浖こ?。今天，統(tǒng)一的流程和UML被廣泛應(yīng)用于各種面向?qū)ο蟮捻?xiàng)目。第四章4.1需求不斷的改變，理解需求問題是軟件工程師面臨的最困難的工作之一，因此他們更少注意需求。在某些情況下，工程師們會化繁為簡。其他情況下，工程師們必須嚴(yán)格地執(zhí)行具體定義的需求。需求分析是設(shè)計(jì)和施工的橋梁,不能跳過。4.2你可以嘗試使用方法比如QFD（質(zhì)量功能部署）通過客戶訪談和觀察、調(diào)查以及檢查歷史數(shù)

19、據(jù)（如問題報(bào)告）為需求收集活動獲取原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯成需求表稱為客戶意見表，并由客戶和利益相關(guān)者評審。接下來使用各種圖表、矩陣和評估方法抽取期望的需求并盡可能導(dǎo)出令人興奮的需求。4.3事實(shí)上,客戶和開發(fā)人員會有一個協(xié)商的過程，開發(fā)人員會要求客戶權(quán)衡產(chǎn)品的性能與產(chǎn)品成本、上市時間之間的關(guān)系。這個協(xié)商的目的是開發(fā)一個項(xiàng)目計(jì)劃，這個計(jì)劃在滿足客戶需求的同時又能準(zhǔn)確反映了軟件開發(fā)過程中約束(如時間、人員、預(yù)算)。不幸的是,這樣的項(xiàng)目計(jì)劃很難達(dá)成,每個客戶都有自己的觀點(diǎn)。這些觀點(diǎn)并不對其他客戶都適用，此外時間是另一個重要的約束,客戶可能沒有時間與開發(fā)人員討論需求，這使得問題更加復(fù)雜。4.4需求

20、模型的目的在于描述所需的信息、功能和計(jì)算機(jī)系統(tǒng)的工作領(lǐng)域。隨著軟件工程師對系統(tǒng)了解的深入以及利益相關(guān)者越來越了解他們真正的需求，這種需求模型是不斷變化的。因此，分析模型在任何時候都是用戶需求的簡介4.5最好的協(xié)商是爭取“雙贏”,這會使你成為是一位談判大師。這些初期步驟的成功實(shí)施可以達(dá)到一個雙贏的結(jié)果，這是繼續(xù)開展后續(xù)的軟件工程活動的關(guān)鍵。4.6第一組上下文無關(guān)問題集主要關(guān)注的是客戶、總體目標(biāo)和利益。例如，需求工程師可能會問：誰是這項(xiàng)工作的最初請求者？誰將使用該解決方案？成功的解決方案將帶來什么樣的經(jīng)濟(jì)收益？對于這個解決方案你還需要其他資源嗎？4.7-4.9答案略。4.10用例圖描述了參與者所能

21、觀察到模型圖。用例圖鼓勵系統(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)目建模時可以重復(fù)使用。4.13最好的協(xié)商是爭取“雙贏”的結(jié)果，即利益相關(guān)者的“贏”在于獲得滿足客戶大多數(shù)需要的系統(tǒng)或產(chǎn)品，而作為軟件團(tuán)隊(duì)一員的“贏”在于按照實(shí)際情況、在可實(shí)現(xiàn)的預(yù)算和時間期限內(nèi)完成工作。4.14當(dāng)需求確認(rèn)解釋了一個錯誤時，每個需求有一個問題清單。之后會有評審小組尋找它

22、。確認(rèn)需求的評審小組包括軟件工程師、客戶、用戶、和其他利益相關(guān)者，他們在檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯誤，以及可能需要進(jìn)一步解釋澄清的地方、丟失的信息、不一致性（這是建造大型產(chǎn)品或系統(tǒng)時遇到的主要問題）、沖突的需求或是不可實(shí)現(xiàn)的（不能達(dá)到的）需求。第五章5.1有沒有可能在分析建模創(chuàng)建后立即開始編碼？解釋你的答案，然后說服反方。答：分析模型作為領(lǐng)域?qū)ο蟮脑O(shè)計(jì)和結(jié)構(gòu)的基礎(chǔ)服務(wù)。在定義了對象和屬性后，就可以開始進(jìn)行編碼，也就知道了對象之間的關(guān)系。5.2 一個單憑經(jīng)驗(yàn)的分析原則是：模型“應(yīng)該關(guān)注在問題域或業(yè)務(wù)域中可見的需求”。在這些域中哪些類型的需求是不可見的？提供一些例子。答：正如我們所知道

23、的，在開始階段很可能沒有完整的需求規(guī)范?？蛻艨赡懿皇欠浅＞_地確定他們的所有需求。開發(fā)者也沒有把握使用一個具體的方法來正常的完成系統(tǒng)的功能和性能。為了需求分析和建模，不傾向使用迭代的方法。分析師所將認(rèn)識到的東西進(jìn)行建模，并使用此模型作為軟件增量的設(shè)計(jì)的基礎(chǔ)。軟件增量作為流程迭代的一部分被制作出來。在這些領(lǐng)域中，需求的類型是不可見的，可能因?yàn)橐恍┕δ鼙仨氃谙到y(tǒng)中實(shí)現(xiàn)，系統(tǒng)展示的行為是什么，屬性定義的接口有哪些，應(yīng)用的約束有哪些？5.3 域分析的目的是什么？如何將域分析與需求模式概念相聯(lián)系？答：域分析是持續(xù)的軟件工程活動，不與任何的軟件項(xiàng)目相關(guān)聯(lián)。它與需求模式的概念相聯(lián)系。域分析是通過一系列活動進(jìn)

24、行表征的過程。這些活動從識別域開始，以描述域中對象和類的規(guī)范為結(jié)束。5.4 有沒有可能不完成如圖6-3所示的4種元素就開發(fā)出一個有效的分析模型？解釋一下。答：如果沒有圖6.3所示的4大元素，是不可能開發(fā)出一個有效的分析模型。分析模型作為域?qū)ο蟮脑O(shè)計(jì)和建造的基礎(chǔ)。5.5 構(gòu)建如下系統(tǒng)中的一個：a你所在大學(xué)基于網(wǎng)絡(luò)的課程注冊系統(tǒng)。b一個計(jì)算機(jī)商店的基于Web的訂單處理系統(tǒng)。c一個小企業(yè)的簡單發(fā)票系統(tǒng)。d內(nèi)置于電磁灶或微波爐的互聯(lián)網(wǎng)食譜。選擇你感興趣的系統(tǒng)開發(fā)一套試題關(guān)系圖并說明數(shù)據(jù)對象、關(guān)系和屬性。答：需要強(qiáng)調(diào)的是，所有的數(shù)據(jù)對象和關(guān)系一定客戶可見的。為了確認(rèn)屬性正確地反映出系統(tǒng)的需求，屬性應(yīng)該被

25、檢查。（無固定答案）5.6-5.9答案略。5.10 什么是分析包？如何使用分析包？答：將分析模型的各種元素以包組的方式進(jìn)行分類，成為分析包。為了說明分析包的作用，請思考一下視頻游戲。作為視頻游戲的分析模型，道出了大量的類。第六章6.1 對于需求分析，結(jié)構(gòu)分析與面向?qū)ο蟛呗杂泻伪举|(zhì)區(qū)別？答：結(jié)構(gòu)分析，考慮把數(shù)據(jù)作為分離實(shí)體的變形的數(shù)據(jù)和過程。數(shù)據(jù)目標(biāo)是被使用它們已被定義的屬性和關(guān)系建模的。過程操作數(shù)據(jù)目標(biāo)是被使用它們在系統(tǒng)中的數(shù)據(jù)流向建模的。面向?qū)ο蠓治?，集中于類的定義和它們合作對用戶需求所帶來的效果的方式。6.2 在數(shù)據(jù)流圖中，一個箭頭表示控制流還是其他？答：DFD數(shù)據(jù)目標(biāo)是用有標(biāo)簽的箭頭所表

26、示的。6.3 什么是“信息流連續(xù)性”？當(dāng)重新定義一個數(shù)據(jù)流時，如何應(yīng)用它？答：數(shù)據(jù)流動連續(xù)性意味著在同一等級中的輸入和輸出必須和它們的精確等級相同。6.4 在生成DFD圖時，如何使用圖形化解析？答：在第一次需求整合會議中，應(yīng)用工程描述中分離所有名詞和動詞的第一步被導(dǎo)出。再文法解析中，動詞時處理和可以被如DFD中的Bubbles描述的。名詞是DFD中的外部實(shí)體（盒子），數(shù)據(jù)或控制目標(biāo)（箭頭），或數(shù)據(jù)存儲（雙實(shí)線）。6.5 什么是控制規(guī)格說明？答：控制規(guī)格（CSPEC）以兩種不同的方式描述了系統(tǒng)的行為（在被提到的基準(zhǔn)線上），CSPEC包括一系列行為的規(guī)格的狀態(tài)圖。它也包括程序行為表組合的行為規(guī)格。

27、6.6 PSPEC和用例是同一事物嗎？如果不是，請解釋區(qū)別。答：不是。過程規(guī)格被用于去描述所有現(xiàn)在最終精煉等級的流程模型過程（算法觀點(diǎn)）。一個有用的情況描述一系列行為包括演員和系統(tǒng)（更著重于用戶可見行為而非算法）。6.7 表示行為建模時有兩種不同“狀態(tài)”類型，它們是什么？答：被動狀態(tài)展現(xiàn)出目標(biāo)屬性的正確情況。主動狀態(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.96.10答案略。第七章7.1是的，但是設(shè)計(jì)是隱式進(jìn)行的通常以隨意的方式進(jìn)行的。在設(shè)計(jì)過程中，

28、我們研究程序的表現(xiàn)形式，而非程序本身。7.2軟件設(shè)計(jì)的目的是運(yùn)用一系列的原則、概念和實(shí)踐導(dǎo)致高質(zhì)量體系或產(chǎn)品的發(fā)展。設(shè)計(jì)的目標(biāo)是創(chuàng)建一個可以正確地實(shí)現(xiàn)所有客戶需求并有好的用戶體驗(yàn)的軟件模型。7.3通過開展一系列的正式技術(shù)評審來評估質(zhì)量。正式技術(shù)評審是由軟件團(tuán)隊(duì)成員召開的會議。通常，根據(jù)將要評審的設(shè)計(jì)信息的范圍，選擇2人、3人或4人參與。每個人扮演一個角色：評判組長策劃會議、擬定議程并主持會議；記錄員記錄筆記以保證沒有遺漏；制作人是指其工作產(chǎn)品（例如某個軟件構(gòu)件的設(shè)計(jì)）被評審的人。在技術(shù)評審會議結(jié)束后，軟件團(tuán)隊(duì)決定未來的行動以來完成最終的產(chǎn)品。7.4為了開發(fā)一個完整的設(shè)計(jì)模型，軟件團(tuán)隊(duì)反復(fù)地開發(fā)

29、每個模塊的元素。每次迭代提供額外的細(xì)節(jié)并且細(xì)化。此外，設(shè)計(jì)任務(wù)應(yīng)用于一個項(xiàng)目可能不同于他們應(yīng)用其他項(xiàng)目。團(tuán)隊(duì)必須適應(yīng)一個通用的任務(wù)集去滿足產(chǎn)品，人和項(xiàng)目的需要。質(zhì)量的評估在有被修改的錯誤的組件級的設(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ú)解決的子問題解決一個復(fù)雜的問題，一個問題的不同部分是相互結(jié)合的方式，給與不同的考慮，而不是合并考慮更復(fù)雜的情況。高度耦合的問題表現(xiàn)出這一特征。然

30、而，問題的部分繼續(xù)組合，因?yàn)樾畔⒘砍^了解一個人的能力不能無限期地進(jìn)行下去，因此，當(dāng)問題非真，模塊化可以修改，但不能消除。7.9在某些時間關(guān)鍵應(yīng)用程序下,可能需要單塊集成軟件。然而,如果軟件是模塊化實(shí)現(xiàn)，設(shè)計(jì)可以而且應(yīng)該實(shí)現(xiàn)的?！澳K”是內(nèi)聯(lián)編碼。7.10信息隱藏與耦合和內(nèi)聚概念有關(guān)，通過限制信息的可用性，只限于那些絕對需要的模塊，模塊之間的耦合在本質(zhì)上是降低了。在一般情況下，信息隔離謂詞有隔離功能，因此，各模塊凝聚力也可以改善7.11外部環(huán)境、編譯器和操作系統(tǒng)耦合將對軟件可移植性造成不利影響。例如,考慮一個程序,這個程序被設(shè)計(jì)用來充分利用智能終端的特殊圖形的特征。如果沒有終端的軟件被搬到一個

31、系統(tǒng),主要設(shè)計(jì)和代碼可能需要修改。7.12我們創(chuàng)建一個功能體系由此來提煉問題。例如，考慮到檢查寫入，我們可能這樣寫：Refinement 1:Write dollar amount in wordsRefinement 2:Procedure write amount;Validate amount is within bounds;Parse to determine each dollar unit;Generate alpha representation;end write_amountRefinement 3:procedure write_amount;do while check

32、s remain to be printedif dollar amount > upper amount boundthen print "amount too large errormessage;else set process flag true;End if;determine maximum significant digit;do while (process flag true andsignificant digits remain)set for corresponded alpha phrase;divide to determine whole numb

33、ervalue;concatenate partial alpha string;reduce significant digit count by one;End doprint alpha string;End doend 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ù)太大”的錯誤信息否則確定過程標(biāo)志符為1。結(jié)束判斷。當(dāng)過程標(biāo)志符

34、為1和有效數(shù)字存在的話，進(jìn)入下面的循環(huán)：確定最高有效位;設(shè)置對應(yīng)阿爾法短語;劃分來確定整數(shù)值；連接部分字符串;7.13略7.14不，重構(gòu)是一種不改變代碼的外部行為和其功能而改善軟件產(chǎn)品的內(nèi)部質(zhì)量的過程。他可能是提高了一個函數(shù)的處理速度或者在另一個系統(tǒng)中起到簡化組件的作用。7.15四個要素的設(shè)計(jì)模型： 設(shè)計(jì)模型的四個元素：數(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ì)描述軟件元素,硬件元素和用戶終端通信。組件等級設(shè)計(jì)建立由軟件組件的程序描述中的軟件結(jié)構(gòu)所定義的元素結(jié)構(gòu)變形。第八章8.1用一個房屋或建筑結(jié)構(gòu)作比喻，與軟件體

35、系結(jié)構(gòu)作對照分析。經(jīng)典建筑與軟件體系結(jié)構(gòu)的原則有什么相似之處？又有何區(qū)別？答：建筑與軟件在風(fēng)格與模式的概念存在于宏觀與微觀層面。例如所有的方子都有總體風(fēng)格（墻、頂、地基）。這些代表了房子的宏觀風(fēng)格。微觀上的模式（房子）可以在木材的類別、壁爐的設(shè)計(jì)以及窗戶上體現(xiàn)出來。軟件體系結(jié)構(gòu)也一樣，不同部件通過不同方法的組裝，形成了不同的系統(tǒng)。不同點(diǎn)：一個比較實(shí)際，另外一個比較抽象；房屋或建筑物可變化的空間比較小，軟件體系結(jié)構(gòu)變化跨度更大一點(diǎn)8.2舉出2到3個例子，說明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é)中

36、主要功能是計(jì)算的應(yīng)用程序。調(diào)用和返回結(jié)構(gòu)：任何I-P-O申請。面對對象的體系結(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ū)ο?。非分層體系結(jié)構(gòu)可能是應(yīng)用面對對象和驅(qū)動編程技術(shù)的最好實(shí)現(xiàn)。8.4 在軟件體系結(jié)構(gòu)討論中，經(jīng)常會遇到體系結(jié)構(gòu)風(fēng)格、體系結(jié)構(gòu)模式及框架（本書中沒有討論）等術(shù)語。研究并描述這些術(shù)語之間的不同。答：許多人把

37、建筑模式和建筑風(fēng)格等價定義（把通用系統(tǒng)模型作為程序設(shè)計(jì)的起始點(diǎn)），盡管模式往往不太廣泛。一個框架可能會被一些人定義為一組提供了一個通用的解決問題方案的類，被解決的問題可以被細(xì)化到創(chuàng)建一個應(yīng)用程序。8.5 選擇一個你熟悉的應(yīng)用，回答8.3.3節(jié)中對于控制與數(shù)據(jù)提出的每一個問題。答：答案不固定。8.6 研究ATAM（Kaz98）并對8.5.1節(jié)提出的6個步驟進(jìn)行詳細(xì)討論。答：答案不固定。8.7 如果還沒有完成習(xí)題5.6，請先完成它。使用本章描述的設(shè)計(jì)方法開發(fā)PHTRS的軟件體系結(jié)構(gòu)。答：答案不固定。8.8 使用數(shù)據(jù)流圖和過程說明，描述一個有清楚變換流特征的計(jì)算機(jī)系統(tǒng)。定義流邊界并使用8.6.1節(jié)描

38、述的技術(shù)將DFD映射到軟件體系結(jié)構(gòu)中答：答案不固定。第九章9.1構(gòu)件級設(shè)計(jì)定義了數(shù)據(jù)結(jié)構(gòu)、算法，界面特性以及分配給每個軟件構(gòu)件的通信機(jī)制。在面向?qū)ο笳Z言中（JAVA或Smalltalk）構(gòu)件為類或?qū)ο?。在傳統(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òu)件（模塊）位于層次結(jié)構(gòu)（體系結(jié)構(gòu)）頂層附近，而問題域構(gòu)件則傾向位于層次結(jié)構(gòu)的底層。為了獲得有效的模塊化，在構(gòu)建細(xì)化的

39、過程中采用了功能獨(dú)立性的設(shè)計(jì)概念。9.3OCP原則模塊（構(gòu)件）應(yīng)該對外延具有開放性，對修改具有封閉性。設(shè)計(jì)者應(yīng)該采用一種無需對結(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)件級設(shè)計(jì)中面向?qū)ο笙到y(tǒng)的上下文中，內(nèi)聚性意味著構(gòu)件或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件或者類自身有密切關(guān)系的屬性和操作。高內(nèi)聚的構(gòu)件會與其他構(gòu)件提供的服務(wù)“絕緣”，從

40、而使其實(shí)施與維護(hù)更加容易。9.6耦合是類之間彼此聯(lián)系程度的一種定性度量。隨著類（構(gòu)件）相互依賴越來越多，類之間的耦合程度亦會增加。低耦合的好處是構(gòu)件可以被修改但不會影響其他構(gòu)件。9.7外部耦合發(fā)生在組件通信或與基礎(chǔ)設(shè)施組件(如。、操作系統(tǒng)功能、數(shù)據(jù)庫功能、通信功能)。雖然這種類型的耦合是必要的,它應(yīng)該是局限于一小部分系統(tǒng)組件或類。軟件必須在內(nèi)部和外部溝通。因此,耦合是一個不爭的事實(shí)。然而,設(shè)計(jì)師應(yīng)盡可能減少耦合和理解高耦合的影響不可避免。9.8略9.9 重構(gòu)是系統(tǒng)決策集散控制的過程，目的是讓頂層模塊執(zhí)行控制功能，而底層模塊處理所有輸入，執(zhí)行和輸出工作。逐步求精是通過連續(xù)精化過程細(xì)節(jié)層次來實(shí)現(xiàn)程

41、序的開發(fā)。在傳統(tǒng)軟件開發(fā)中兩者是很相似的。9.10WebAPP構(gòu)件定義為以下兩點(diǎn)之一：定義良好的聚合功能，為最終用戶處理內(nèi)容，或提供計(jì)算或數(shù)據(jù)處理內(nèi)容和功能的聚合包，提供最終用戶所需的功能。9.11略9.12略9.13略9.14 人可以短暫記憶一小部分東西，分塊可以使評審者將相關(guān)概念組合成大的碎片或更大的分塊。那些具有分塊功能的構(gòu)件（如果構(gòu)件具有高內(nèi)聚低耦合特性）可以使評審者在設(shè)計(jì)審查時更簡單的追蹤幾個構(gòu)件的相互作用而不是大量的單各類或方法。第十章10.1這道題應(yīng)該不難！許多早期交互式系統(tǒng)都有糟糕的界面。在現(xiàn)代環(huán)境下，讓你的學(xué)生們注重基于web的應(yīng)用程序界面。許多web應(yīng)用程序?yàn)榱薋lash犧

42、牲易用性。10.2例子如下：在它們引起“可撤銷的”損害之前抓住潛在的交互錯誤。允許用戶自定義屏幕布局以及命令。利用分離菜單，以便通用功能。10.3例子如下：如果用戶有需求，在屏幕上一直顯示快捷鍵命令序列。當(dāng)一個web應(yīng)用程序需要密碼輸入的時候，提供“密碼提示”機(jī)制。10.4例子如下：使用一致的顏色，例如，紅色用作警示信息，藍(lán)色用作通知信息；提供關(guān)鍵字驅(qū)動的在線幫助。10.5答案略。10.6如果你的學(xué)生在任務(wù)分析上出了問題，老的備用I-P-O將會有效。問：使用者輸入什么？它是怎么處理的？處理過程是如何通過界面表現(xiàn)出來的？產(chǎn)生的輸出是什么？10.7-10.11答案略。10.12當(dāng)響應(yīng)時間無法預(yù)測的

43、時候，使用者會很不耐煩并且重復(fù)嘗試請求的命令或者嘗試另一個命令。在某些情況下，這會產(chǎn)生（命令的）排隊(duì)問題，并且在極端的情況下，會引起數(shù)據(jù)的丟失或者甚至是一個系統(tǒng)故障。研究表明，用戶可以容忍他們熟悉的應(yīng)用程序的響應(yīng)率50%的變化。對于那些不熟悉的應(yīng)用程序，使用者在15到30秒意外的延遲（也就是他們短期記憶的半衰期）后會很焦慮。10.13答案略。10.14如果你想要給你的學(xué)生一些工作項(xiàng)目表的范例，互聯(lián)網(wǎng)是一個很好的可用性調(diào)查表的來源（大部分都應(yīng)該有超過20道的問題，所以你的學(xué)生應(yīng)該需要優(yōu)先考慮他們的選擇）第十四章14.1用自己的話描述驗(yàn)證與確認(rèn)的區(qū)別。兩者都要用測試用例的設(shè)計(jì)方法和測試策略嗎？答：

44、“驗(yàn)證”是通過嘗試在功能或性能上發(fā)現(xiàn)錯誤來保證程序的正確性，“確認(rèn)”是保證軟件與需求相一致這也是質(zhì)量的基本特征。14.2列出一些可能與獨(dú)立測試組（ITG）的創(chuàng)建相關(guān)的問題。IGT與SQA小組由相同的人員組成嗎？答：組建ITG（獨(dú)立測試組）最常見的問題是獲得并留住人才，除此之外，如果ITG與軟件工程小組的交流組織地不恰當(dāng)?shù)脑挘瑑山M之間可能會產(chǎn)生敵意。最后，ITG有可能太晚接手項(xiàng)目，導(dǎo)致沒有時間完成一個周密測試的計(jì)劃和執(zhí)行。ITG和SQA（軟件質(zhì)量保證）小組不必是同一組人。ITG只關(guān)注測試，SQA小組則需要考慮到質(zhì)量保證相關(guān)的所有方面。14.3使用14.1.3節(jié)中描述的測試步驟來建立測試軟件的策略

45、總是可行的嘛？對于嵌入式系統(tǒng)，出現(xiàn)哪些可能的復(fù)雜情況？答：它并不總是能夠進(jìn)行單元測試的測試環(huán)境，完成單元測試的復(fù)雜性（如復(fù)雜的驅(qū)動和存根）可能無法證明效益。集成測試是復(fù)雜的通過單元測試的模塊合并計(jì)劃的有效性（特別是當(dāng)這些模塊滯后的時候）。在很多情況下（尤其是嵌入式系統(tǒng)）軟件不能充分進(jìn)行驗(yàn)證測試硬件配置外的目標(biāo)。因此，驗(yàn)證和系統(tǒng)測試要相結(jié)合。14.4為什么對具有較高耦合度的模塊進(jìn)行單元測試？答：一個高度耦合的模塊要與其他模塊的數(shù)據(jù)和其他系統(tǒng)元素進(jìn)行交互。因此，其功能往往是依賴于這些耦合元件的操作。為了徹底的單元測試這樣一個模塊，耦合因素的功能必須以某種方式模擬。這將會是困難和費(fèi)時的。14.5“防

46、錯法”的概念是一個非常有效的方法。當(dāng)發(fā)現(xiàn)錯誤時，他提供了內(nèi)置調(diào)試幫助：a. 為防錯發(fā)開發(fā)一組知道原則。b. 討論利用這種技術(shù)的優(yōu)點(diǎn)。c. 討論利用這種技術(shù)的缺點(diǎn)。答：一個單一的規(guī)則涵蓋了多種情況：所有數(shù)據(jù)在軟件接口（外部和內(nèi)部）應(yīng)當(dāng)經(jīng)過驗(yàn)證（如果可能的話）。優(yōu)點(diǎn)：錯誤不會“滾雪球”越滾越大缺點(diǎn)：需要額外的處理時間和內(nèi)存（那通常只是一個很小的代價）。14.6項(xiàng)目的進(jìn)度安排是如何影響集成測試的？答：完成模塊的可用性的影響順序和戰(zhàn)略整合。項(xiàng)目狀態(tài)必須是已知的，可以成功地實(shí)現(xiàn)整合規(guī)劃。14.7在所有的情況下，單元測試都是可能的或是值得做的嗎？提供實(shí)例來說明你的理由。答：如果一個模塊有3或4個下屬供應(yīng)數(shù)

47、據(jù)模塊的一個有意義的評價是至關(guān)重要的，沒有“聚類”所有的模塊作為一個單元，它可能無法進(jìn)行單元測試。14.8誰應(yīng)該完成確認(rèn)測試是軟件開發(fā)人員還是軟件的使用者，說明你的理由。答：開發(fā)商，如果客戶驗(yàn)收測試計(jì)劃。開發(fā)人員和客戶（用戶）如果沒有進(jìn)一步的測試計(jì)劃。一個獨(dú)立的測試組可能是這里最好的選擇，但這不是一個選擇。14.9為本書討論的safehouse系統(tǒng)開發(fā)一個完整的測試策略，并以測試規(guī)格說明的方式形成文檔。答：略14.10作為一個班級項(xiàng)目，為你的安裝開發(fā)調(diào)試指南。這個指南應(yīng)該提供面向語言和面向系統(tǒng)的建議。這些建議是通過總結(jié)學(xué)校學(xué)習(xí)過程中所遇到的挫折得到的。從一個經(jīng)過全班和老師評審過的大綱開始，并在

48、你局部范圍內(nèi)將這個指南發(fā)布給其他人。答：略第十五章15.1 Myersmye79用以下程序作為測試能力的自我評估：某程序讀入三個整數(shù)值表示三角形的三條邊。改程序打印信息表明三角形是不規(guī)則的，等腰的或等邊的。開發(fā)一組測試用例測試改程序。答：參考Myersmye79對此問題提出的極其詳細(xì)的“解決方案”。15.2設(shè)計(jì)并實(shí)現(xiàn)15.1描述的程序（適當(dāng)使用錯誤處理）。從該程序中導(dǎo)出流圖并用基本路徑測試方法設(shè)計(jì)測試，以保證程序中的所有語句都被測試到。執(zhí)行測試用例并顯示結(jié)果。答：你可以選擇發(fā)布程序源代碼給您的學(xué)生（故意地嵌入一些錯誤）。15.3你能夠想出15.1.1節(jié)中沒有討論的其他測試目標(biāo)嗎？答：除了那些目

49、標(biāo)之外還有：a) 一個成功的測試顯示功能和性能要求；b) 一個成功的測試發(fā)現(xiàn)文件錯誤；c) 一個成功的測試發(fā)現(xiàn)接口問題；d) 一個成功的測試驗(yàn)證了程序結(jié)構(gòu)，了解數(shù)據(jù)結(jié)構(gòu)，界面設(shè)計(jì)和程序設(shè)計(jì)；e) 一個成功的測試，建立了一個進(jìn)入一個測試案例數(shù)據(jù)庫，以后可以用于回歸測試。15.4選擇一個你最近設(shè)計(jì)和實(shí)現(xiàn)的構(gòu)建。設(shè)計(jì)一組測試用例，保證利用基本路徑測試執(zhí)行所有語句。答：略15.5-15.8答：進(jìn)行一些拓展，這些問題可以被指定為一個長期的項(xiàng)目。15.9至少給出三個例子，在這些例子中，黑盒測試能給人“一切正?！钡挠∠?，而白盒測試可能發(fā)現(xiàn)錯誤。再至少給出三個例子，在這些例子中白盒測試能給人“一切正常”的印象

50、，而黑盒測試可能發(fā)現(xiàn)錯誤。答：對于特定的輸入，一個內(nèi)部發(fā)生的錯誤導(dǎo)致：1) 不恰當(dāng)?shù)臄?shù)據(jù)被設(shè)在一個全局?jǐn)?shù)據(jù)域里；2) 不恰當(dāng)?shù)臉?biāo)記將在隨后進(jìn)行的一系列測試中被測試；3) 不恰當(dāng)硬件控制，只可能在系統(tǒng)測試時被發(fā)現(xiàn)；但是卻產(chǎn)生了正確的輸出。15.10不，即使窮舉測試（如果可能的話）也不能發(fā)現(xiàn)軟件說明書中的性能問題和錯誤。在這種情況下需要同時考慮輸入和輸出的等價類。對每一個類來說，學(xué)生應(yīng)當(dāng)根據(jù)數(shù)值范圍，集合的元素，系統(tǒng)命令等劃定邊界。這可以作為筆試以及一些著名應(yīng)用GUI的測試用例的素材15.11生成一系列用例來幫助測試用戶的文件材料是一個好辦法。第十六章16.1用自己的話，描述為什么在面向?qū)ο笙到y(tǒng)中

51、，類是最小的合理測試單元。答：類封裝了數(shù)據(jù)以及處理數(shù)據(jù)的操作。由于數(shù)據(jù)和操作被打包成一個整體，一個一個地測試方法沒有作用，不能發(fā)現(xiàn)與消息傳送，職責(zé)和協(xié)作相關(guān)的錯誤。16.2若現(xiàn)有類已進(jìn)行了徹底的測試，為什么我們必須對從現(xiàn)有類 實(shí)例化的子類進(jìn)行重新測試？我們可以使用為現(xiàn)有類設(shè)計(jì)的測試用例么？答：由于每一個子類都繼承了父類的私有屬性和操作（事實(shí)上這些私有屬性和操作會增加復(fù)雜度），這些子類必須在他們的操作環(huán)境中重新測試。測試用例可以重復(fù)使用，但需要針對子類的私有屬性和操作進(jìn)行擴(kuò)充。16.3為什么“測試”應(yīng)該從面向?qū)ο蠓治龊驮O(shè)計(jì)開始？答：在之后的開發(fā)過程中，面向?qū)ο蠓治龊驮O(shè)計(jì)模型提供了大量與系統(tǒng)結(jié)構(gòu)和

52、行為相關(guān)的信息，因此，在生成代碼之前，這些模型必須經(jīng)過嚴(yán)格的審查。所有面向?qū)ο蟮哪Ｐ蛻?yīng)當(dāng)在模型的語法，語義以及語用論的上下中經(jīng)過正確性，完整性，一致性的測試（包括技術(shù)評審）。這些評審有可能省去很多不必要的工作和修改（錯誤越早發(fā)現(xiàn)，維護(hù)的成本越低）。16.4為SafeHome導(dǎo)出一組CRC索引卡片，按照16.2.2節(jié)講述的步驟確定是否存在不一致性。答：答案會有不同16.5基于線程和基于使用的集成測試策略有什么不同？簇測試如何適應(yīng)？答：基于線程的測試用來集成一系列需要對單獨(dú)一個程序輸入或事件響應(yīng)的類?；谑褂玫臏y試屬于集成測試的一種，通過測試那些很少使用服務(wù)器類的類（稱為獨(dú)立類）開始系統(tǒng)的構(gòu)造。測

53、試完獨(dú)立類之后，測試使用獨(dú)立類的下一層類（稱為依賴類），按照這樣的順序逐層測試依賴類直到整個系統(tǒng)構(gòu)造完成。16.6將隨機(jī)測試和劃分方法運(yùn)用到設(shè)計(jì)SafeHome系統(tǒng)時定義的3個類。產(chǎn)生展示操作調(diào)用序列的測試用例。答：答案會有不同16.7運(yùn)用多類測試及從SafeHome設(shè)計(jì)的行為模型中生成的測試。答：答案會有不同16.8運(yùn)用隨機(jī)測試、劃分方法、多類測試及16.5節(jié)和16.6節(jié)所描述的銀行應(yīng)用的行為模型導(dǎo)出的測試，再生成另外生成4個測試。答：答案會有不同第十八章18.1基于本章給出的信息和自己的經(jīng)驗(yàn)，列舉出能夠增強(qiáng)軟件工程師能力的“十條戒律”。即，列出10條指導(dǎo)原則，使得軟件人員能夠在工作中發(fā)揮其

54、全部潛力。答：（1）你要變得更聰明。（2）你要注重質(zhì)量。（3）你要傾聽客戶。（4）你要了解問題（5）你要對一個工作過程不斷的重復(fù)。（6）你不可同意荒唐的時間表。（7）你要測量產(chǎn)品，過程和你自己。（8）你要制定最有效的工作方法。（9）你要記住，別人也會軟件工作。（10）你要不斷地提高。18.2 SEI的人員能力成熟度模型定義了培養(yǎng)優(yōu)秀軟件人員的“關(guān)鍵實(shí)踐域”。你的老師將為你指派一個關(guān)鍵實(shí)踐域，請你對它進(jìn)行分析和總結(jié)。答：略。18.3描述3種現(xiàn)實(shí)生活中的實(shí)際情況，其中客戶和最終用戶是相同的人。也描述3種他們是不同人的情況。答：相同的人：（1）一個工程師必須開發(fā)一個供個人使用的程序。（2）一個商人創(chuàng)

55、建供個人使用的電子表格模型。（3）一個擁有迷人的手機(jī)客戶端這一新概念的企業(yè)家。不同的人：（1）一個通信部門的一些業(yè)務(wù)功能的服務(wù)。（2）一個軟件開發(fā)團(tuán)隊(duì)服務(wù)營銷的需求。（3）承包商建立的客戶的規(guī)格。18.4高級管理者所做的決策會對軟件工程團(tuán)隊(duì)的效率產(chǎn)生重大影響。也描述3種他們是不同人的情況。答：在今天的環(huán)境，裁員和外包有最直接的、重大的影響。此外，“減少開支的措施”，導(dǎo)致較低的產(chǎn)品質(zhì)量；不切實(shí)際的項(xiàng)目最后期限；對用戶的需求了解失??；或者，反過來說，對軟件工程師的工作提出警告。18.5溫習(xí)Weiberg的書Wei86，并寫出一份2-3頁的總結(jié)，說明在使用MOI模型時應(yīng)該考慮的問題。答案：略。18.6在一個信息系統(tǒng)組織中，你被指派為項(xiàng)目經(jīng)理。你的工作是開發(fā)一個應(yīng)用程序，該程序類似于你的團(tuán)隊(duì)已經(jīng)做過的項(xiàng)目，只是規(guī)模更大而且更復(fù)雜。需求已經(jīng)由用戶改寫成文檔。你會選擇哪種團(tuán)隊(duì)結(jié)構(gòu)？為什么？你會選擇哪（些）種軟件過程模型？為什么？答：一個封閉范型方法的團(tuán)隊(duì)結(jié)構(gòu)是一種選擇。由于需求明確，這可能會要求和配置多個分區(qū)小組。規(guī)模大的項(xiàng)目緩和了利于CD團(tuán)隊(duì)的方面。由于沒有討論日程，我們假設(shè)的交貨日期是合理的。因此，有可能使用一個線性的順序過程模型。然而，迭代模型（例如，螺旋）也是一個很好的可能性。18.7你被指派為一個小型軟件產(chǎn)