軟件工程課后習題答案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21、觀察到模型圖。用例圖鼓勵系統(tǒng)的功能視圖應該轉(zhuǎn)換為面向?qū)ο蟮囊晥D。在許多情況下，為了提供更多的相互作用，用例圖需要做更詳細的闡述。4.11任何有一些軟件項目需求工程經(jīng)驗的人都開始注意到，在特定的應用領(lǐng)域內(nèi)某些事情在所有的項目中重復發(fā)生。這些分析模式在特定應用領(lǐng)域內(nèi)提供了一些解決方案（如類、功能、行為），在為許多應用項目建模時可以重復使用。4.13最好的協(xié)商是爭取“雙贏”的結(jié)果，即利益相關(guān)者的“贏”在于獲得滿足客戶大多數(shù)需要的系統(tǒng)或產(chǎn)品，而作為軟件團隊一員的“贏”在于按照實際情況、在可實現(xiàn)的預算和時間期限內(nèi)完成工作。4.14當需求確認解釋了一個錯誤時，每個需求有一個問題清單。之后會有評審小組尋找它

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

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

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

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

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

27、6.6 PSPEC和用例是同一事物嗎？如果不是，請解釋區(qū)別。答：不是。過程規(guī)格被用于去描述所有現(xiàn)在最終精煉等級的流程模型過程（算法觀點）。一個有用的情況描述一系列行為包括演員和系統(tǒng)（更著重于用戶可見行為而非算法）。6.7 表示行為建模時有兩種不同“狀態(tài)”類型，它們是什么？答：被動狀態(tài)展現(xiàn)出目標屬性的正確情況。主動狀態(tài)指明了目標在轉(zhuǎn)化或執(zhí)行過程中的正確情況。6.8 如何從狀態(tài)圖區(qū)分順序圖？它們有何相似之處？答：狀態(tài)圖描述了系統(tǒng)的狀態(tài)并且展現(xiàn)了事件如何影響系統(tǒng)狀態(tài)。順序圖指明了事件如何引起目標的遷移。6.96.10答案略。第七章7.1是的，但是設計是隱式進行的通常以隨意的方式進行的。在設計過程中，

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

29、每個模塊的元素。每次迭代提供額外的細節(jié)并且細化。此外，設計任務應用于一個項目可能不同于他們應用其他項目。團隊必須適應一個通用的任務集去滿足產(chǎn)品，人和項目的需要。質(zhì)量的評估在有被修改的錯誤的組件級的設計任務集。任務集在章節(jié)中給出。7.5略7.6軟件體系結(jié)構(gòu)是程序組件（模塊）的結(jié)構(gòu)或組織，這些組件相互作用的方式和數(shù)據(jù)結(jié)構(gòu)被這些組件所使用。然而在更廣泛的意義上講，部件可以推廣到代表主要的系統(tǒng)元件以及它們之間的交互。7.7略7.8分離關(guān)注點涉及通過將其分成單獨解決的子問題解決一個復雜的問題，一個問題的不同部分是相互結(jié)合的方式，給與不同的考慮，而不是合并考慮更復雜的情況。高度耦合的問題表現(xiàn)出這一特征。然

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

31、系統(tǒng),主要設計和代碼可能需要修改。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細化1：寫出大寫金額總數(shù)。細化2：寫出大寫金額數(shù)的程序：驗證金額數(shù)是否在允許范圍內(nèi)；通過解析來確定美元單位;用來表示金額數(shù)，寫出來;結(jié)束寫出大寫金額數(shù)程序細化3：寫出大寫金額數(shù)的程序：檢查是否還有未打印的支票，如有進入下面的循環(huán)判斷支票金額數(shù)是否大于上面指定的金額數(shù)如果大于打印“金額數(shù)太大”的錯誤信息否則確定過程標志符為1。結(jié)束判斷。當過程標志符

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

35、系結(jié)構(gòu)作對照分析。經(jīng)典建筑與軟件體系結(jié)構(gòu)的原則有什么相似之處？又有何區(qū)別？答：建筑與軟件在風格與模式的概念存在于宏觀與微觀層面。例如所有的方子都有總體風格（墻、頂、地基）。這些代表了房子的宏觀風格。微觀上的模式（房子）可以在木材的類別、壁爐的設計以及窗戶上體現(xiàn)出來。軟件體系結(jié)構(gòu)也一樣，不同部件通過不同方法的組裝，形成了不同的系統(tǒng)。不同點：一個比較實際，另外一個比較抽象；房屋或建筑物可變化的空間比較小，軟件體系結(jié)構(gòu)變化跨度更大一點8.2舉出2到3個例子，說明8.3.1節(jié)中提到的每一種體系結(jié)構(gòu)風格的應用。答：數(shù)據(jù)中心體系結(jié)構(gòu):航空訂票系統(tǒng)；圖書館目錄系統(tǒng)；賓館訂閱系統(tǒng)。數(shù)據(jù)流結(jié)構(gòu)：任何工程或科學中

36、主要功能是計算的應用程序。調(diào)用和返回結(jié)構(gòu)：任何I-P-O申請。面對對象的體系結(jié)構(gòu)：基于GUI的應用程序;任何面向?qū)ο蟮膽贸绦?。分層體系結(jié)構(gòu)：應用功能必須從底層操作系統(tǒng)或網(wǎng)絡詳細信息分離的應用程序。客戶端服務器軟件通常是分層的。8.3 8.3.1節(jié)中提到的一些體系結(jié)構(gòu)風格具有層次性，而另一些則沒有。列出每種類型。沒有層次的體系風格如何實現(xiàn)？答:層次：數(shù)據(jù)流，調(diào)用返回層。非層次：數(shù)據(jù)中心，面向?qū)ο?。非分層體系結(jié)構(gòu)可能是應用面對對象和驅(qū)動編程技術(shù)的最好實現(xiàn)。8.4 在軟件體系結(jié)構(gòu)討論中，經(jīng)常會遇到體系結(jié)構(gòu)風格、體系結(jié)構(gòu)模式及框架（本書中沒有討論）等術(shù)語。研究并描述這些術(shù)語之間的不同。答：許多人把

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

38、述的技術(shù)將DFD映射到軟件體系結(jié)構(gòu)中答：答案不固定。第九章9.1構(gòu)件級設計定義了數(shù)據(jù)結(jié)構(gòu)、算法，界面特性以及分配給每個軟件構(gòu)件的通信機制。在面向?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)件是由分析模型所導出的。然而在這種情況下，導出構(gòu)件是以分析模型中面向數(shù)據(jù)流元素作為基礎。數(shù)據(jù)流圖的最低層的每個變換都被映射為某一層上的模塊。控制構(gòu)件（模塊）位于層次結(jié)構(gòu)（體系結(jié)構(gòu)）頂層附近，而問題域構(gòu)件則傾向位于層次結(jié)構(gòu)的底層。為了獲得有效的模塊化，在構(gòu)建細化的

39、過程中采用了功能獨立性的設計概念。9.3OCP原則模塊（構(gòu)件）應該對外延具有開放性，對修改具有封閉性。設計者應該采用一種無需對結(jié)構(gòu)自身內(nèi)部（代碼或內(nèi)部邏輯）做修改就可以進行的擴展（在構(gòu)建所確定的功能域內(nèi)）的方式來說明構(gòu)件。設計者進行抽象，在那些需要擴展的功能與設計類本身之間起到緩沖區(qū)作用。9.4依賴性倒置原則(DIP)，依賴于抽象。不依賴于具體實現(xiàn)。構(gòu)件依賴的其他具體構(gòu)件（不是依賴抽象類，如接口）越多，擴展起來越困難。9.5構(gòu)件級設計中面向?qū)ο笙到y(tǒng)的上下文中，內(nèi)聚性意味著構(gòu)件或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件或者類自身有密切關(guān)系的屬性和操作。高內(nèi)聚的構(gòu)件會與其他構(gòu)件提供的服務“絕緣”，從

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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