軟件工程課后習題答案

/第一章1.1舉出至少5個例子來說明“意外效應法則”在計算機軟件方面的應用。答：典型的例子包括運用“數(shù)字汽車儀表板”的軟件，賜予高科技，高品質(zhì)的圖像的軟件；如廣泛的消費類電子產(chǎn)品的軟件；個人電腦，工業(yè)儀器儀表和機器的軟件。軟件分化出的在電子商務方面的應用。1.2舉例說明軟件對社會的影響（包括正面影響和負面影響）。答：這是一個很好的課堂探討問題（假如時間允許），而不是專注于老生常談的（但很重要）隱私問題，生活質(zhì)量等問題。您可能想要探討關于”技術恐驚“方面的問題，軟件或許會使它惡化但也可能削減”技術恐驚“。另一個好玩的方面是運用諾依曼的“風險”列在SEN中做重點探討。你也可以考慮基于軟件的“現(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）依靠的技術仍處于開發(fā)階段，從而延長日程支配。開發(fā)成本高：a）比當時預期低得令人無法接受的質(zhì)量，須要進行更多的測試，設計和實施工作。b）制定了錯誤的軟件功能須要重新設計和實施。c）開發(fā)錯誤的用戶界面，而導致重新設計和實施。d）開發(fā)了不須要的額外的軟件功能而延長了開發(fā)日程支配。在將軟件交付顧客運用之前，我們無法找到全部錯誤：a）產(chǎn)品依靠于政府監(jiān)管，意外而變更。b）產(chǎn)品技術標準草案，會意外更改。c）有時會在項目后期添加新的開發(fā)人員。d）因為團隊內(nèi)的沖突有時會導致溝通不暢，而產(chǎn)生糟糕的設計。e）破壞高效調(diào)度產(chǎn)生的項目管理成果和無效的規(guī)劃f）有時裝備部件質(zhì)量差，導致額外的測試，設計和集成工作和管理額外的客戶關系。軟件開發(fā)和維護的過程照舊難以度量：a）有時該項目的目的是不明確。b）有大量的業(yè)務所涉及的風險。c）假如產(chǎn)品內(nèi)置沒有裝好。d）我們須要不斷檢討我們的工作。e）進行維護檢查的時間。f）在整個軟件開發(fā)過程中要徹底組織項目團隊。1.4在交付最終用戶之前，或者首個版本投入運用之后，許多應用程序都會有常見的變更。為防止變更引起軟件退化，請?zhí)岢鲆恍┯行У慕鉀Q措施。答：許多現(xiàn)代應用程序在他們呈現(xiàn)給最終用戶之前和第一個版本別運用后經(jīng)常變更，以下幾個方面來阻擋軟件惡化：a)收集所需的信息。b)設計師和客戶定義軟件的總體目標。c)識別已知的需求。d)運用現(xiàn)有的程序片段后，有助于建立原型的開發(fā)人員的工作支配快速完成。e)只有通過合格的培訓或閱歷和充分揭露相關的不足，才能保持和提高我們的技術實力和讓f)其他人擔當技術任務g)文件應當被剛好制定出來，在文件中應當有標準定義和機制建立。h)完成某一特定階段的審查工作。i)每一個關鍵團隊成員應當配有一個后備人員j)檢查規(guī)避風險的步驟是否應用正確k)對將來的風險分析中檢查是否有必要收集必要的信息。1.5思索1.1.2節(jié)中提到的7個軟件分類。請問能否接受一個軟件工程方法，應用于全部的軟件分類？并就你的答案加以說明。答：七個軟件分類可應用于同樣的方法。在這不確定的今日這些“新的挑戰(zhàn)”，無疑有很大的影響（對于商務人士，軟件工程師和最終用戶來說）然而，軟件工程師可以準備通過實例化一個過程，使其有足夠的靈敏性和適應性，以適應猛烈變更的技術，這技術確定要在將來的很長一段時間被商業(yè)規(guī)則所接受。1.6圖1-3中，將軟件工程三個層次放在了“質(zhì)量關注點”這層之上。這意味著在整個開發(fā)組織內(nèi)接受質(zhì)量管理活動，如“全面質(zhì)量管理”。細致探討，并列出全面質(zhì)量管理活動中關鍵原則的大綱。答：你或許建議同學閱讀第十六章的學問來解決問題。1.7隨著軟件的普及，由于程序錯誤所帶來的公眾風險已經(jīng)成為一個愈加重要的問題。設想一個真實場景，由于軟件錯誤而引起“世界末日”般重大危害（危害社會經(jīng)濟或是人類生命財產(chǎn)平安）。答：的確有許多現(xiàn)實生活中的狀況來選擇，例如，軟件錯誤，造成了重大的電話網(wǎng)絡失敗。如在航空電子設備故障導致飛機墜毀。計算機病毒（如米開朗基羅）的攻擊給主要的電子商務網(wǎng)站造成了重大的經(jīng)濟損失。1.8用自己的話描述過程框架。當我們談到框架活動適用于全部的項目時，是否意味著對于不同規(guī)模和困難度的項目，可應用相同的工作任務？請說明。答：過程框架適用于全部的項目，在相同的工作任務，適用于全部項目，無論其規(guī)模大小或困難性。一個過程框架涉及大量的和客戶溝通來收集需求；這個活動建立了一個軟件工程工作支配。它涉及到創(chuàng)建模型，這將有助于開發(fā)人員了解顧客的要求從而進行設計。從而涉及構建（代碼生成和錯誤測試）。最終，它供應了基于評價的反饋。1.9普適性活動存在于整個軟件過程中，你認為他們勻整分布于軟件過程中，還是會集中在某個或者某些框架活動中？答：傘活動在整個軟件過程中發(fā)生，它們被勻整地應用在整個過程中，分析還包含一系列的工作任務（例如需求收集，制定，協(xié)商規(guī)范和驗證），一個過程框架有一組傘被應用在整個軟件過程活動中。這些活動包括：軟件項目跟蹤和限制，風險管理，軟件質(zhì)量保證，和正式的技術審查，測量，軟件配置管理，可重用性管理和工作產(chǎn)品的制作和生產(chǎn)。1.10在1.5節(jié)所列舉的神話中，增加兩種軟件神話，同時指出和其相對應的真實狀況。答：沒有標準答案（例如測試可以解決全部的程序錯誤）。其次章2.1在本章的介紹中，Baetjer說過：“軟件過程為用戶和設計者之間、用戶和開發(fā)工具之間以及設計者和開發(fā)工具之間供應交互的途徑[技術]”。對于要構建的軟件產(chǎn)品，在以下方面設計五個問題：（a）設計者應當問用戶的問題；（b）用戶應當問設計者的問題；（c）用戶對將要構建的軟件自問的問題；（d）設計者對于軟件產(chǎn)品和建立該產(chǎn)品實行的軟件過程自問的問題。答：a）設計人員詢問用戶：產(chǎn)品滿意嗎或者它須要重新設計或返工嗎？征求用戶輸入來避開產(chǎn)品不滿意和要求返工。有新要求的須要嗎？該產(chǎn)品比估計的大嗎？和預期的相比模塊須要更多的測試，設計和實行工作來訂正嗎？b)用戶詢問設計者的問題：范圍明確嗎？我們是否有開發(fā)工具和人員開發(fā)軟件所需的技能？定義的需求是正確的嗎？還有沒有額外的須要？特定領域的軟件產(chǎn)品比平常的花費更多的時間嗎？該模塊是否須要更多的設計測試？c）用戶對將要構建的軟件自問的問題：軟件產(chǎn)品的范圍和目的是什么?該產(chǎn)品比估計的大嗎？有優(yōu)秀的人可用嗎？工作人員牢靠嗎有沒有具備所須要的技能？能保持工作人員的離職率足夠低嗎？d）設計者對于軟件產(chǎn)品和建立該產(chǎn)品實行的軟件過程自問的問題：范圍和目的文件是什么？要運用什么樣的工具？有什么目標和規(guī)避風險的優(yōu)先事項？對風險分析，識別，估計，評價和管理睬有什么樣的步驟？2.2為溝通活動設計一些列的動作，選定一個動作作為其設計一個任務集。答：任務溝通活動設置：任務組將定義實際的工作須要，以完成一個軟件工程的行動。這些都是對于通信的活動：a）利益相關者對項目做一個列表。b）邀請全部利益相關者的非正式會議。c）要求他們作出特性和功能列表。d）探討需求并建立一個最終的的列表。e）他不確定的優(yōu)先級的要求和要留意的地方。這些任務可能是一個困難的軟件項目，然后，他們可能包括：a)要進行一系列的規(guī)范會議，基于利益相關者的輸入，建立了初步的功能和特性列表。b)要建立一個股權持有人要求的修訂清單。c)運用質(zhì)量功能綻開技術來滿意需求。d)留意在系統(tǒng)上的約束和限制。e)探討驗證系統(tǒng)的方法。2.3在溝通過程中，遇到兩位對軟件如何做有著不同想法的利益相關者是很常見的問題。也就是說你得到了相互沖突的需求。設計一種過程模式（可以是步驟模式），利用2.13節(jié)中針對此類問題的模板，給出一種行之有效的解決方法。答：模式名：利益相關者的需求沖突。意圖：此模式描述的方式是解決利益相關者之間在通信框架活動中的沖突。類型：階段模式。初始背景：(1)利益相關者已確定(2)利益相關者和軟件工程師已經(jīng)建立了協(xié)作通信(3)軟件要解決的主要問題由軟件開發(fā)團隊已建立。(4)對已開發(fā)的項目范圍，基本的業(yè)務需求和項目的限制有了初步的了解。問題：對正在開發(fā)的軟件，利益相關者的需求出現(xiàn)了相互的沖突。解決方法：全部的利益相關者被要求區(qū)分需求的優(yōu)先級，短暫保住利益相關者的優(yōu)先級最高或投票的最多的需求從而解決這一問題。結(jié)果：由利益相關方的確定的需求優(yōu)先依次列表來指導軟件開發(fā)團隊構件軟件初始模型。相關模式：定義指導和協(xié)作方針，范圍隔離，需求收集，約束描述和混合需求。已知用途/范例：必要的溝通是貫穿整個軟件工程中。2.4閱讀[Nog001]，然后寫一篇2-3頁的論文，探討混亂對軟件工程的影響。答案略。2.5詳細描述三個適用于接受瀑布模型的軟件項目。答：適合瀑布模型的項目例如數(shù)據(jù)結(jié)構，軟件架構，程序的微小環(huán)節(jié)和接口表征的對象。2.6詳細描述三個適用于接受原型模型的軟件項目。答：相對簡潔的原型模型幾乎總是涉及人機交互和/或困難計算機圖形軟件應用程序，有時適合原型模型是某些類別的數(shù)學算法，叮囑驅(qū)動系統(tǒng)和其他應用在沒有實時交互時結(jié)果可以很簡潔地檢查。難以用原型模型的應用程序，包括限制和過程限制功能許多種類的實時應用程序和嵌入式軟件。2.7假如將原型變成一個可發(fā)布的系統(tǒng)或產(chǎn)品，應當如何調(diào)整過程？答：假如將原型變成一個可發(fā)布的系統(tǒng)或產(chǎn)品，軟件工程師和客戶須要滿意和定義軟件的總體目標，識別已知的任何要求，對整體輪廓進一步的強制定義。原型作為一種機制，用于識別軟件需求。假如一個工作原型被建立了，開發(fā)商會試圖利用現(xiàn)有的程序片段或應用工具（例如，報表生成器，窗口管理等）使工作方案，可以快速生成。2.8詳細描述三個適于接受增量模型的軟件項目。答:每一個線性序列產(chǎn)生的“增量”交付的軟件，例如字處理軟件開發(fā)運用增量范式可能會供應基本的文件管理，編輯和文件制作功能在第一增量，更困難的編輯和文件制作實力在其次增量；拼法和語法檢查在第三增量，先進的頁面布局實力在第四增量。任何增量的處理流程可以納入原型范式。增量發(fā)展是特殊有用當人員無法在經(jīng)營期限為一個已成立的項目做完備的實施。2.9當沿著螺旋過程流發(fā)展的時候，你對正在開發(fā)或者維護的軟件的看法是什么？答：隨著工作的螺旋向外移動，產(chǎn)品走向一個更完整的狀態(tài)，執(zhí)行工作的抽象層次削減了。2.10可以合用幾種過程模型嗎？假如可以，舉例說明。答：過程模型可以合用，每個模型都有個有點不同的處理流程，但都執(zhí)行相同的通用框架活動集：溝通，規(guī)劃，建模，施工和交付/反饋。例如線性依次模型可以作為一個有用的過程模型，在被固定的狀況下，要求工作以線性的方式接著進行，直至完成。在這狀況下，開發(fā)者可能無法確定一種算法的效率，一個操作系統(tǒng)的適應性或應實行的人機交互的形式。在這之中，以及許多其他場合原型模型可以供應最好的方法。在其他狀況下，以漸進的方式可能是有意義的和螺旋模型的流淌可能是有效率，特殊過程模型具有許多的一個或多個傳統(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ā)速度超過了產(chǎn)品的質(zhì)量，這可能會導致許多缺陷，該軟件可能須要更多的測試，設計和實施工作。需求定以的不是很清楚，可能須要不斷地變更。半調(diào)子和速度過快開發(fā)都可能導致無法檢測到重大的項目風險。質(zhì)量太差可能導致過多的質(zhì)量問題和常見的返工。2.13詳細描述三個適于接受基于構件模型的軟件項目。答：我會建議推遲這個問題直到“軟件過程改進”這一章。2.14我們可以證明一個軟件構件甚至整個程序的正確性，可是為什么并不是每個人都這樣做？答：這是可能的用數(shù)學技術來證明軟件組件，甚至整個程序的正確性。然而，對于困難的程序，這是一個特殊耗時的過程。用詳盡的測試是不行能證明任何不平凡的程序的正確性，2.15統(tǒng)一過程和UML是同一概念嗎？說明你的答案。答：UML供應了必要的技術支持和面對對象的軟件工程實踐。但它并不供應流程框架來指導項目團隊，在他們的技術應用中。在近幾年中，雅各布森，Rumbaugh和Booch制定的統(tǒng)一過程中框架運用UML的面對對象的軟件工程。今日，統(tǒng)一的流程和UML被廣泛應用于各種面對對象的項目。第四章4.1需求不斷的變更，理解需求問題是軟件工程師面臨的最困難的工作之一，因此他們更少留意需求。在某些狀況下，工程師們會化繁為簡。其他狀況下，工程師們必需嚴格地執(zhí)行詳細定義的需求。需求分析是設計和施工的橋梁,不能跳過。4.2你可以嘗試運用方法比如QFD（質(zhì)量功能部署）通過客戶訪談和視察、調(diào)查以及檢查歷史數(shù)據(jù)（如問題報告）為需求收集活動獲得原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯成需求表——稱為客戶看法表，并由客戶和利益相關者評審。接下來運用各種圖表、矩陣和評估方法抽取期望的需求并盡可能導出令人興奮的需求。4.3事實上,客戶和開發(fā)人員會有一個協(xié)商的過程，開發(fā)人員會要求客戶權衡產(chǎn)品的性能和產(chǎn)品成本、上市時間之間的關系。這個協(xié)商的目的是開發(fā)一個項目支配，這個支配在滿意客戶需求的同時又能精確反映了軟件開發(fā)過程中約束(如時間、人員、預算)。不幸的是,這樣的項目支配很難達成,每個客戶都有自己的觀點。這些觀點并不對其他客戶都適用，此外時間是另一個重要的約束,客戶可能沒有時間和開發(fā)人員探討需求，這使得問題更加困難。4.4需求模型的目的在于描述所需的信息、功能和計算機系統(tǒng)的工作領域。隨著軟件工程師對系統(tǒng)了解的深化以及利益相關者越來越了解他們真正的需求，這種需求模型是不斷變更的。因此，分析模型在任何時候都是用戶需求的簡介4.5最好的協(xié)商是爭取“雙贏”,這會使你成為是一位談判大師。這些初期步驟的成功實施可以達到一個雙贏的結(jié)果，這是接著開展后續(xù)的軟件工程活動的關鍵。4.6第一組上下文無關問題集主要關注的是客戶、總體目標和利益。例如，需求工程師可能會問：誰是這項工作的最初請求者？誰將運用該解決方案？成功的解決方案將帶來什么樣的經(jīng)濟收益？對于這個解決方案你還須要其他資源嗎？4.7-4.9答案略。4.10用例圖描述了參和者所能視察到模型圖。用例圖激勵系統(tǒng)的功能視圖應當轉(zhuǎn)換為面對對象的視圖。在許多狀況下，為了供應更多的相互作用，用例圖須要做更詳細的闡述。4.11任何有一些軟件項目需求工程閱歷的人都起先留意到，在特定的應用領域內(nèi)某些事情在全部的項目中重復發(fā)生。這些分析模式在特定應用領域內(nèi)供應了一些解決方案（如類、功能、行為），在為許多應用項目建模時可以重復運用。4.13最好的協(xié)商是爭取“雙贏”的結(jié)果，即利益相關者的“贏”在于獲得滿意客戶大多數(shù)須要的系統(tǒng)或產(chǎn)品，而作為軟件團隊一員的“贏”在于依據(jù)實際狀況、在可實現(xiàn)的預算和時間期限內(nèi)完成工作。4.14當需求確認說明白一個錯誤時，每個需求有一個問題清單。之后會有評審小組找尋它。確認需求的評審小組包括軟件工程師、客戶、用戶、和其他利益相關者，他們在檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或說明上的錯誤，以及可能須要進一步說明澄清的地方、丟失的信息、不一樣性（這是建立大型產(chǎn)品或系統(tǒng)時遇到的主要問題）、沖突的需求或是不行實現(xiàn)的（不能達到的）需求。第五章5.1有沒有可能在分析建模創(chuàng)建后立刻起先編碼？說明你的答案，然后勸服反方。答：分析模型作為領域?qū)ο蟮脑O計和結(jié)構的基礎服務。在定義了對象和屬性后，就可以起先進行編碼，也就知道了對象之間的關系。5.2一個單憑閱歷的分析原則是：模型“應當關注在問題域或業(yè)務域中可見的需求”。在這些域中哪些類型的需求是不行見的？供應一些例子。答：正如我們所知道的，在起先階段很可能沒有完整的需求規(guī)范。客戶可能不是特殊精確地確定他們的全部需求。開發(fā)者也沒有把握運用一個詳細的方法來正常的完成系統(tǒng)的功能和性能。為了需求分析和建模，不傾向運用迭代的方法。分析師所將相識到的東西進行建模，并運用此模型作為軟件增量的設計的基礎。軟件增量作為流程迭代的一部分被制作出來。在這些領域中，需求的類型是不行見的，可能因為一些功能必需在系統(tǒng)中實現(xiàn)，系統(tǒng)展示的行為是什么，屬性定義的接口有哪些，應用的約束有哪些？5.3域分析的目的是什么？如何將域分析和需求模式概念相聯(lián)系？答：域分析是持續(xù)的軟件工程活動，不和任何的軟件項目相關聯(lián)。它和需求模式的概念相聯(lián)系。域分析是通過一系列活動進行表征的過程。這些活動從識別域起先，以描述域中對象和類的規(guī)范為結(jié)束。5.4有沒有可能不完成如圖6-3所示的4種元素就開發(fā)出一個有效的分析模型？說明一下。答：假如沒有圖6.3所示的4大元素，是不行能開發(fā)出一個有效的分析模型。分析模型作為域?qū)ο蟮脑O計和建立的基礎。5.5構建如下系統(tǒng)中的一個：a你所在高?；诰W(wǎng)絡的課程注冊系統(tǒng)。b一個計算機商店的基于Web的訂單處理系統(tǒng)。c一個小企業(yè)的簡潔發(fā)票系統(tǒng)。d內(nèi)置于電磁灶或微波爐的互聯(lián)網(wǎng)食譜。選擇你感愛好的系統(tǒng)開發(fā)一套試題關系圖并說明數(shù)據(jù)對象、關系和屬性。答：須要強調(diào)的是，全部的數(shù)據(jù)對象和關系確定客戶可見的。為了確認屬性正確地反映出系統(tǒng)的需求，屬性應當被檢查。（無固定答案）5.6-5.9答案略。5.10什么是分析包？如何運用分析包？答：將分析模型的各種元素以包組的方式進行分類，成為分析包。為了說明分析包的作用，請思索一下視頻游戲。作為視頻游戲的分析模型，道出了大量的類。第六章6.1對于需求分析，結(jié)構分析和面對對象策略有何本質(zhì)區(qū)分？答：結(jié)構分析，考慮把數(shù)據(jù)作為分別實體的變形的數(shù)據(jù)和過程。數(shù)據(jù)目標是被運用它們已被定義的屬性和關系建模的。過程操作數(shù)據(jù)目標是被運用它們在系統(tǒng)中的數(shù)據(jù)流向建模的。面對對象分析，集中于類的定義和它們合作對用戶需求所帶來的效果的方式。6.2在數(shù)據(jù)流圖中，一個箭頭表示限制流還是其他？答：DFD數(shù)據(jù)目標是用有標簽的箭頭所表示的。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ī)格。6.6PSPEC和用例是同一事物嗎？假如不是，請說明區(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.9——6.10答案略。第七章7.1是的，但是設計是隱式進行的——通常以隨意的方式進行的。在設計過程中，我們探討程序的表現(xiàn)形式，而非程序本身。7.2軟件設計的目的是運用一系列的原則、概念和實踐導致高質(zhì)量體系或產(chǎn)品的發(fā)展。設計的目標是創(chuàng)建一個可以正確地實現(xiàn)全部客戶需求并有好的用戶體驗的軟件模型。7.3通過開展一系列的正式技術評審來評估質(zhì)量。正式技術評審是由軟件團隊成員召開的會議。通常，依據(jù)將要評審的設計信息的范圍，選擇2人、3人或4人參和。每個人扮演一個角色：評判組長策劃會議、擬定議程并主持會議；記錄員記錄筆記以保證沒有遺漏；制作人是指其工作產(chǎn)品（例如某個軟件構件的設計）被評審的人。在技術評審會議結(jié)束后，軟件團隊確定將來的行動以來完成最終的產(chǎn)品。7.4為了開發(fā)一個完整的設計模型，軟件團隊反復地開發(fā)每個模塊的元素。每次迭代供應額外的微小環(huán)節(jié)并且細化。此外，設計任務應用于一個項目可能不同于他們應用其他項目。團隊必需適應一個通用的任務集去滿意產(chǎn)品，人和項目的須要。質(zhì)量的評估在有被修改的錯誤的組件級的設計任務集。任務集在章節(jié)中給出。7.5略7.6軟件體系結(jié)構是程序組件（模塊）的結(jié)構或組織，這些組件相互作用的方式和數(shù)據(jù)結(jié)構被這些組件所運用。然而在更廣泛的意義上講，部件可以推廣到代表主要的系統(tǒng)元件以及它們之間的交互。7.7略7.8分別關注點涉及通過將其分成單獨解決的子問題解決一個困難的問題，一個問題的不同部分是相互結(jié)合的方式，給和不同的考慮，而不是合并考慮更困難的狀況。高度耦合的問題表現(xiàn)出這一特征。然而，問題的部分接著組合，因為信息量超過了解一個人的實力不能無限期地進行下去，因此，當問題非真，模塊化可以修改，但不能消退。7.9在某些時間關鍵應用程序下,可能須要單塊集成軟件。然而,假如軟件是模塊化實現(xiàn)，設計可以而且應當實現(xiàn)的。“模塊”是內(nèi)聯(lián)編碼。7.10信息隱藏和耦合和內(nèi)聚概念有關，通過限制信息的可用性，只限于那些確定須要的模塊，模塊之間的耦合在本質(zhì)上是降低了。在一般狀況下，信息隔離謂詞有隔離功能，因此，各模塊凝合力也可以改善7.11外部環(huán)境、編譯器和操作系統(tǒng)耦合將對軟件可移植性造成不利影響。例如,考慮一個程序,這個程序被設計用來充分利用智能終端的特殊圖形的特征。假如沒有終端的軟件被搬到一個系統(tǒng),主要設計和代碼可能須要修改。7.12我們創(chuàng)建一個功能體系由此來提煉問題。例如，考慮到檢查寫入，我們可能這樣寫：Refinement1:WritedollaramountinwordsRefinement2:Procedurewriteamount;Validateamountiswithinbounds;Parsetodetermineeachdollarunit;Generatealpharepresentation;endwrite_amountRefinement3:procedurewrite_amount;dowhilechecksremaintobeprintedifdollaramount>upperamountboundthenprint"amounttoolargeerrormessage;elsesetprocessflagtrue;Endif;determinemaximumsignificantdigit;dowhile(processflagtrueandsignificantdigitsremain)setforcorrespondedalphaphrase;dividetodeterminewholenumbervalue;concatenatepartialalphastring;reducesignificantdigitcountbyone;Enddoprintalphastring;Enddoendwrite_amount細化1：寫出大寫金額總數(shù)。細化2：寫出大寫金額數(shù)的程序：驗證金額數(shù)是否在允許范圍內(nèi)；通過解析來確定美元單位;用來表示金額數(shù)，寫出來;結(jié)束寫出大寫金額數(shù)程序細化3：寫出大寫金額數(shù)的程序：檢查是否還有未打印的支票，如有進入下面的循環(huán) 推斷支票金額數(shù)是否大于上面指定的金額數(shù) 假如大于打印“金額數(shù)太大”的錯誤信息 否則確定過程標記符為1。 結(jié)束推斷。當過程標記符為1和有效數(shù)字存在的話，進入下面的循環(huán)：確定最高有效位;設置對應阿爾法短語;劃分來確定整數(shù)值；連接部分α字符串;7.13略7.14不，重構是一種不變更代碼的外部行為和其功能而改善軟件產(chǎn)品的內(nèi)部質(zhì)量的過程。他可能是提高了一個函數(shù)的處理速度或者在另一個系統(tǒng)中起到簡化組件的作用。7.15四個要素的設計模型：設計模型的四個元素：數(shù)據(jù)/類設計——建立由分析轉(zhuǎn)化的基于類內(nèi)元素的類模型和按數(shù)據(jù)結(jié)構要求實現(xiàn)的軟件。結(jié)構設計——定義大體軟件元素結(jié)構件的關系。接口設計——描述軟件元素,硬件元素和用戶終端通信。組件等級設計——建立由軟件組件的程序描述中的軟件結(jié)構所定義的元素結(jié)構變形。第八章8.1用一個房屋或建筑結(jié)構作比方，和軟件體系結(jié)構作比照分析。經(jīng)典建筑和軟件體系結(jié)構的原則有什么相像之處？又有何區(qū)分？答：建筑和軟件在風格和模式的概念存在于宏觀和微觀層面。例如全部的方子都有總體風格（墻、頂、地基）。這些代表了房子的宏觀風格。微觀上的模式（房子）可以在木材的類別、壁爐的設計以及窗戶上體現(xiàn)出來。軟件體系結(jié)構也一樣，不同部件通過不同方法的組裝，形成了不同的系統(tǒng)。不同點：一個比較實際，另外一個比較抽象；房屋或建筑物可變更的空間比較小，軟件體系結(jié)構變更跨度更大一點8.2舉出2到3個例子，說明8.3.1節(jié)中提到的每一種體系結(jié)構風格的應用。答：數(shù)據(jù)中心體系結(jié)構:航空訂票系統(tǒng)；圖書館書目系統(tǒng)；賓館訂閱系統(tǒng)。數(shù)據(jù)流結(jié)構：任何工程或科學中主要功能是計算的應用程序。調(diào)用和返回結(jié)構：任何I-P-O申請。面對對象的體系結(jié)構：基于GUI的應用程序;任何面對對象的應用程序。分層體系結(jié)構：應用功能必需從底層操作系統(tǒng)或網(wǎng)絡詳細信息分別的應用程序?？蛻舳朔掌鬈浖ǔＪ欠謱拥?。8.38.3.1節(jié)中提到的一些體系結(jié)構風格具有層次性，而另一些則沒有。列出每種類型。沒有層次的體系風格如何實現(xiàn)？答:層次：數(shù)據(jù)流，調(diào)用返回層。非層次：數(shù)據(jù)中心，面對對象。非分層體系結(jié)構可能是應用面對對象和驅(qū)動編程技術的最好實現(xiàn)。8.4在軟件體系結(jié)構探討中，經(jīng)常會遇到體系結(jié)構風格、體系結(jié)構模式及框架（本書中沒有探討）等術語。探討并描述這些術語之間的不同。答：許多人把建筑模式和建筑風格等價定義（把通用系統(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é)構。答：答案不固定。8.8運用數(shù)據(jù)流圖和過程說明，描述一個有清楚變換流特征的計算機系統(tǒng)。定義流邊界并運用8.6.1節(jié)描述的技術將DFD映射到軟件體系結(jié)構中答：答案不固定。第九章9.1構件級設計定義了數(shù)據(jù)結(jié)構、算法，界面特性以及支配給每個軟件構件的通信機制。在面對對象語言中（JAVA或Smalltalk）構件為類或?qū)ο?。在傳統(tǒng)語言(C或Fortran)中構件式函數(shù)或操作過程。在混合語言中（如C++）構件可能是函數(shù)或類。9.2像面對對象的構件一樣，傳統(tǒng)軟件構件是由分析模型所導出的。然而在這種狀況下，導出構件是以分析模型中面對數(shù)據(jù)流元素作為基礎。數(shù)據(jù)流圖的最低層的每個變換都被映射為某一層上的模塊。限制構件（模塊）位于層次結(jié)構（體系結(jié)構）頂層旁邊，而問題域構件則傾向位于層次結(jié)構的底層。為了獲得有效的模塊化，在構建細化的過程中接受了功能獨立性的設計概念。9.3OCP原則模塊（構件）應當對外延具有開放性，對修改具有封閉性。設計者應當接受一種無需對結(jié)構自身內(nèi)部（代碼或內(nèi)部邏輯）做修改就可以進行的擴展（在構建所確定的功能域內(nèi)）的方式來說明構件。設計者進行抽象，在那些須要擴展的功能和設計類本身之間起到緩沖區(qū)作用。9.4依靠性倒置原則(DIP)，依靠于抽象。不依靠于詳細實現(xiàn)。構件依靠的其他詳細構件（不是依靠抽象類，如接口）越多，擴展起來越困難。9.5構件級設計中面對對象系統(tǒng)的上下文中，內(nèi)聚性意味著構件或者類只封裝那些相互關聯(lián)密切，以及和構件或者類自身有密切關系的屬性和操作。高內(nèi)聚的構件會和其他構件供應的服務“絕緣”，從而使其實施和維護更加簡潔。9.6耦合是類之間彼此聯(lián)系程度的一種定性度量。隨著類（構件）相互依靠越來越多，類之間的耦合程度亦會增加。低耦合的好處是構件可以被修改但不會影響其他構件。9.7外部耦合發(fā)生在組件通信或和基礎設施組件(如。、操作系統(tǒng)功能、數(shù)據(jù)庫功能、通信功能)。雖然這種類型的耦合是必要的,它應當是局限于一小部分系統(tǒng)組件或類。軟件必需在內(nèi)部和外部溝通。因此,耦合是一個不爭的事實。然而,設計師應盡可能削減耦合和理解高耦合的影響不行避開。9.8略9.9重構是系統(tǒng)決策集散限制的過程，目的是讓頂層模塊執(zhí)行限制功能，而底層模塊處理全部輸入，執(zhí)行和輸出工作。逐步求精是通過連續(xù)精化過程微小環(huán)節(jié)層次來實現(xiàn)程序的開發(fā)。在傳統(tǒng)軟件開發(fā)中兩者是很相像的。9.10WebAPP構件定義為以下兩點之一：定義良好的聚合功能，為最終用戶處理內(nèi)容，或供應計算或數(shù)據(jù)處理內(nèi)容和功能的聚合包，供應最終用戶所需的功能。9.11略9.12略9.13略9.14人可以短暫記憶一小部分東西，分塊可以使評審者將相關概念組合成大的碎片或更大的分塊。那些具有分塊功能的構件（假如構件具有高內(nèi)聚低耦合特性）可以使評審者在設計審查時更簡潔的追蹤幾個構件的相互作用而不是大量的單各類或方法。第十章10.1這道題應當不難！許多早期交互式系統(tǒng)都有糟糕的界面。在現(xiàn)代環(huán)境下，讓你的學生們留意基于web的應用程序界面。許多web應用程序為了Flash犧牲易用性。10.2例子如下：在它們引起“可撤銷的”損害之前抓住潛在的交互錯誤。允許用戶自定義屏幕布局以及叮囑。利用分別菜單，以便通用功能。10.3例子如下：假如用戶有需求，在屏幕上始終顯示快捷鍵叮囑序列。當一個web應用程序須要密碼輸入的時候，供應“密碼提示”機制。10.4例子如下：運用一樣的顏色，例如，紅色用作警示信息，藍色用作通知信息；供應關鍵字驅(qū)動的在線幫助。10.5答案略。10.6假如你的學生在任務分析上出了問題，老的備用I-P-O將會有效。問：運用者輸入什么？它是怎么處理的？處理過程是如何通過界面表現(xiàn)出來的？產(chǎn)生的輸出是什么？10.7-10.11答案略。10.12當響應時間無法預料的時候，運用者會很不耐煩并且重復嘗試請求的叮囑或者嘗試另一個叮囑。在某些狀況下，這會產(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ū)分。兩者都要用測試用例的設計方法和測試策略嗎？答：“驗證”是通過嘗試在功能或性能上發(fā)覺錯誤來保證程序的正確性，“確認”是保證軟件和需求相一樣——這也是質(zhì)量的基本特征。14.2列出一些可能和獨立測試組（ITG）的創(chuàng)建相關的問題。IGT和SQA小組由相同的人員組成嗎？答：組建ITG（獨立測試組）最常見的問題是獲得并留住人才，除此之外，假如ITG和軟件工程小組的溝通組織地不恰當?shù)脑?，兩組之間可能會產(chǎn)生敵意。最終，ITG有可能太晚接手項目，導致沒有時間完成一個周密測試的支配和執(zhí)行。ITG和SQA（軟件質(zhì)量保證）小組不必是同一組人。ITG只關注測試，SQA小組則須要考慮到質(zhì)量保證相關的全部方面。14.3運用14.1.3節(jié)中描述的測試步驟來建立測試軟件的策略總是可行的嘛？對于嵌入式系統(tǒng)，出現(xiàn)哪些可能的困難狀況？答：它并不總是能夠進行單元測試的測試環(huán)境，完成單元測試的困難性（如困難的驅(qū)動和存根）可能無法證明效益。集成測試是困難的通過單元測試的模塊合并支配的有效性（特殊是當這些模塊滯后的時候）。在許多狀況下（尤其是嵌入式系統(tǒng)）軟件不能充分進行驗證測試硬件配置外的目標。因此，驗證和系統(tǒng)測試要相結(jié)合。14.4為什么對具有較高耦合度的模塊進行單元測試？答：一個高度耦合的模塊要和其他模塊的數(shù)據(jù)和其他系統(tǒng)元素進行交互。因此，其功能往往是依靠于這些耦合元件的操作。為了徹底的單元測試這樣一個模塊，耦合因素的功能必需以某種方式模擬。這將會是困難和費時的。14.5“防錯法”的概念是一個特殊有效的方法。當發(fā)覺錯誤時，他供應了內(nèi)置調(diào)試幫助：為防錯發(fā)開發(fā)一組知道原則。探討利用這種技術的優(yōu)點。探討利用這種技術的缺點。答：一個單一的規(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ù)據(jù)模塊的一個有意義的評價是至關重要的，沒有“聚類”全部的模塊作為一個單元，它可能無法進行單元測試。14.8誰應當完成確認測試——是軟件開發(fā)人員還是軟件的運用者，說明你的理由。答：開發(fā)商，假如客戶驗收測試支配。開發(fā)人員和客戶（用戶）假如沒有進一步的測試支配。一個獨立的測試組可能是這里最好的選擇，但這不是一個選擇。14.9為本書探討的safehouse系統(tǒng)開發(fā)一個完整的測試策略，并以測試規(guī)格說明的方式形成文檔。答：略14.10作為一個班級項目，為你的安裝開發(fā)調(diào)試指南。這個指南應當供應面對語言和面對系統(tǒng)的建議。這些建議是通過總結(jié)學校學習過程中所遇到的挫折得到的。從一個經(jīng)過全班和老師評審過的大綱起先，并在你局部范圍內(nèi)將這個指南發(fā)布給其他人。答：略第十五章15.1Myers[mye79]用以下程序作為測試實力的自我評估：某程序讀入三個整數(shù)值表示三角形的三條邊。改程序打印信息表明三角形是不規(guī)則的，等腰的或等邊的。開發(fā)一組測試用例測試改程序。答：參考Myers[mye79]對此問題提出的極其詳細的“解決方案”。15.2設計并實現(xiàn)15.1描述的程序（適當運用錯誤處理）。從該程序中導出流圖并用基本路徑測試方法設計測試，以保證程序中的全部語句都被測試到。執(zhí)行測試用例并顯示結(jié)果。答：你可以選擇發(fā)布程序源代碼給您的學生（有意地嵌入一些錯誤）。15.3你能夠想出15.1.1節(jié)中沒有探討的其他測試目標嗎？答：除了那些目標之外還有：a)一個成功的測試顯示功能和性能要求；b)一個成功的測試發(fā)覺文件錯誤；c)一個成功的測試發(fā)覺接口問題；d)一個成功的測試驗證了程序結(jié)構，了解數(shù)據(jù)結(jié)構，界面設計和程序設計；e)一個成功的測試，建立了一個進入一個測試案例數(shù)據(jù)庫，以后可以用于回來測試。15.4選擇一個你最近設計和實現(xiàn)的構建。設計一組測試用例，保證利用基本路徑測試執(zhí)行全部語句。答：略答：進行一些拓展，這些問題可以被指定為一個長期的項目。15.9至少給出三個例子，在這些例子中，黑盒測試能給人“一切正?！钡挠∠螅缀袦y試可能發(fā)覺錯誤。再至少給出三個例子，在這些例子中白盒測試能給人“一切正常”的印象，而黑盒測試可能發(fā)覺錯誤。答：對于特定的輸入，一個內(nèi)部發(fā)生的錯誤導致：1)不恰當?shù)臄?shù)據(jù)被設在一個全局數(shù)據(jù)域里；2)不恰當?shù)臉擞泴⒃陔S后進行的一系列測試中被測試；3)不恰當硬件限制，只可能在系統(tǒng)測試時被發(fā)覺；但是卻產(chǎn)生了正確的輸出。15.10不，即使窮舉測試（假如可能的話）也不能發(fā)覺軟件說明書中的性能問題和錯誤。在這種狀況下須要同時考慮輸入和輸出的等價類。對每一個類來說，學生應當依據(jù)數(shù)值范圍，集合的元素，系統(tǒng)叮囑等劃定邊界。這可以作為筆試以及一些著名應用GUI的測試用例的素材15.11生成一系列用例來幫助測試用戶的文件材料是一個好方法。第十六章16.1用自己的話，描述為什么在面對對象系統(tǒng)中，類是最小的合理測試單元。答：類封裝了數(shù)據(jù)以及處理數(shù)據(jù)的操作。由于數(shù)據(jù)和操作被打包成一個整體，一個一個地測試方法沒有作用，不能發(fā)覺和消息傳送，職責和協(xié)作相關的錯誤。16.2若現(xiàn)有類已進行了徹底的測試，為什么我們必需對從現(xiàn)有類實例化的子類進行重新測試？我們可以運用為現(xiàn)有類設計的測試用例么？答：由于每一個子類都繼承了父類的私有屬性和操作（事實上這些私有屬性和操作會增加困難度），這些子類必需在他們的操作環(huán)境中重新測試。測試用例可以重復運用，但須要針對子類的私有屬性和操作進行擴充。16.3為什么“測試”應當從面對對象分析和設計起先？答：在之后的開發(fā)過程中，面對對象分析和設計模型供應了大量和系統(tǒng)結(jié)構和行為相關的信息，因此，在生成代碼之前，這些模型必需經(jīng)過嚴格的審查。全部面對對象的模型應當在模型的語法，語義以及語用論的上下中經(jīng)過正確性，完整性，一樣性的測試（包括技術評審）。這些評審有可能省去許多不必要的工作和修改（錯誤越早發(fā)覺，維護的成本越低）。16.4為SafeHome導出一組CRC索引卡片，依據(jù)16.2.2節(jié)講解并描述的步驟確定是否存在不一樣性。答：答案會有不同16.5基于線程和基于運用的集成測試策略有什么不同？簇測試如何適應？答：基于線程的測試用來集成一系列須要對單獨一個程序輸入或事務響應的類?；谶\用的測試屬于集成測試的一種，通過測試那些很少運用服務器類的類（稱為獨立類）起先系統(tǒng)的構造。測試完獨立類之后，測試運用獨立類的下一層類（稱為依靠類），依據(jù)這樣的依次逐層測試依靠類直到整個系統(tǒng)構造完成。16.6將隨機測試和劃分方法運用到設計SafeHome系統(tǒng)時定義的3個類。產(chǎn)生展示操作調(diào)用序列的測試用例。答：答案會有不同16.7運用多類測試及從SafeHome設計的行為模型中生成的測試。答：答案會有不同16.8運用隨機測試、劃分方法、多類測試及16.5節(jié)和16.6節(jié)所描述的銀行應用的行為模型導出的測試，再生成另外生成4個測試。答：答案會有不同第十八章18.1基于本章給出的信息和自己的閱歷，列舉出能夠增加軟件工程師實力的“十條戒律”。即，列出10條指導原則，使得軟件人員能夠在工作中發(fā)揮其全部潛力。答：（1）你要變得更聰慧。（2）你要留意質(zhì)量。（3）你要傾聽客戶。（4）你要了解問題（5）你要對一個工作過程不斷的重復。（6）你不行同意荒唐的時辰表。（7）你要測量產(chǎn)品，過程和你自己。（8）你要制定最有效的工作方法。（9）你要記住，別人也會軟件工作。（10）你要不斷地提高。18.2SEI的人員實力成熟度模型定義了培育優(yōu)秀軟件人員的“關鍵實踐域”。你的老師將為你指派一個關鍵實踐域，請你對它進行分析和總結(jié)。答：略。18.3描述3種現(xiàn)實生活中的實際狀況，其中客戶和最終用戶是相同的人。也描述3種他們是不同人的狀況。答：相同的人：（1）一個工程師必需開發(fā)一個供個人運用的程序。（2）一個商人創(chuàng)建供個人運用的電子表格模型。（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é)構？為什么？你會選擇哪（些）種軟件過程模型？為什么？答：一個封閉范型方法的團隊結(jié)構是一種選擇。由于需求明確，這可能會要求和配置多個分區(qū)小組。規(guī)模大的項目緩和了利于CD團隊的方面。由于沒有探討日程，我們假設的交貨日期是合理的。因此，有可能運用一個線性的依次過程模型。然而，迭代模型（例如，螺旋）也是一個很好的可能性。18.7你被指派為一個小型軟件產(chǎn)品公司的項目經(jīng)理。你的工作是開發(fā)一個有突破性的產(chǎn)品，該產(chǎn)品結(jié)合了虛擬現(xiàn)實的硬件和超群的軟件。因為家庭消遣市場的競爭特殊激烈，完成這項工作的壓力很大。你會選擇哪種團隊結(jié)構？為什么？你會選擇哪種過程模型？為什么？答：隨機式范型的團隊結(jié)構可能是唯一可行的選擇，給出了模糊的要求和工作性質(zhì)的試驗。應當運用原型開發(fā)方法或者一個曾量的過程模型。18.8你被指派為一個大型軟件產(chǎn)品公司的項目經(jīng)理。你的工作是管理該公司已被廣泛運用的字處理軟件的新版本的開發(fā)。由于競爭激烈，已經(jīng)規(guī)定了緊迫的最終期限，并對外公布。你會選擇哪種團隊結(jié)構？為什么？你會選擇哪些軟件過程模型？為什么？答：一個開放式范型團隊結(jié)構可能是最好的，給定的時間壓力和熟悉的工作（然而，封閉的方法范式團隊可能也很好）。一個曾量過程模型被推動這項工作性質(zhì)的最終期限所指明。18.9在一個為基因工程領域服務的公司中，你被指派為軟件項目經(jīng)理。你的工作是管理一個軟件新產(chǎn)品的開發(fā)，該產(chǎn)品能夠加速基因分類的速度。這項工作是面對探討及開發(fā)的，但其目標是在下一年度內(nèi)生產(chǎn)出產(chǎn)品。你會選擇哪種團隊結(jié)構？為什么？你會選擇哪些軟件過程模型？為什么？答：一個隨機式范型可能是最好的，是因為這項工作是試驗性的，且有一個企業(yè)的最終期限。另一種可能性是運用一個開放式范型的團隊結(jié)構。一個曾量過程模型和進化過程模型可以用于推動賜予限期的這項工作。18.10要求開發(fā)一個小型應用軟件，它的作用是分析一所高校開設的每一門課程，并輸出課程的平均成果（針對某個學期）。寫出該問題的范圍陳述。答：分數(shù)分析應用程序?qū)@得全部本科和探討生的學分課程的成果和在某一學期課程注冊數(shù)據(jù)庫。分數(shù)分析應用程序會讀每一門課程的全部等級和計算平均成果，運用的數(shù)值范圍在A=4和其他等級支配值來作為等級值存到uc29-1文檔。本程序會打印一個報告顯示每門課的老師和平均成果。這個報告可能會按平均成果或者老師等其他類似的特征排序。本程序可能會運行在WindowsVista操作系統(tǒng)下。18.11給出18.3.2節(jié)中探討的頁面布局功能的第一級功能分解。答：一個簡潔的分解：頁面布局定義頁面參數(shù)支配文本區(qū)域支配圖形區(qū)域強調(diào)定義（線，著色等）輸入/導入文本輸入/導入編輯文本編輯圖形出頁/導出頁面最終頁面布局第十九章19.1用自己的話描述過程度量和項目度量之間的區(qū)分。答：過程度量是用來對設計和建立計算機軟件的活動進行評估（為了在后續(xù)項目提高這些活動）。項目度量是用來評估軟件項目的狀態(tài)。19.2為什么有些軟件度量是“私有的”？給出3個私有度量的例子，并給出3個公有度量的例子。答：當待評估的特征無法被干脆測量時一種間接的的測量方法將被運用，例如,“質(zhì)量”不能被干脆測量所以只能測量軟件其他的特征，軟件的許多度量工作都間接的，因為軟件不是一個有形的可以用干脆測量的實體。例子能干脆度量的物體紙的數(shù)量人的數(shù)量不同文件的數(shù)量不能干脆度量的物體可讀性（利用模糊指數(shù)）完整性（計算你收到的”服務臺”問題的數(shù)量）可維護性(定時變更文檔)19.3什么是間接測量？為什么在軟件度量工作中經(jīng)常用到這類測量？答：沒找到答案。19.4Grady提出了一組軟件度量規(guī)則，你能在19.1.1節(jié)所列的規(guī)則中在增加3個規(guī)則嗎？答：軟件度量的額外規(guī)則：不找完備的指標……它不存在。保證測量的一樣性，避開比較不同的事物。留意質(zhì)量，這是最重要的。19.5產(chǎn)品交付之前，團隊A在軟件工程過程中發(fā)覺了342個錯誤，團隊B發(fā)覺了184個錯誤。對于項目A和B，還須要做什么額外的測量，才能確定哪個團隊能夠更有效地解除錯誤？你建議接受什么度量能有助于做出判定？那些歷史數(shù)據(jù)可能有用？答：兩個團隊應當事先確定好要開發(fā)的軟件的大小和功能，例如，errors/FP可以供應一個規(guī)范化的評估方法。此外，在兩個團隊的軟件開發(fā)過程中一個度量標準例如DRE可以供應一個對SQA的效率指標。19.6給出反對將代碼行作為軟件生產(chǎn)率度量的論據(jù)。當考慮幾十個或幾百個項目時，你說的狀況還成立嗎？答：LOC的作用不大是因為它的嘉獎“verbose”支配，同時他也很難用在可視化編程中，4GLs，代碼生成器，或其他的代碼生成器4gts的發(fā)展正在遠離3gls19.7依據(jù)下面的信息域特性，計算項目的功能點值：用戶人數(shù)：32用戶輸出數(shù)：60用戶查詢數(shù)：24文件數(shù)：8外部接口數(shù)：2假定全部的困難度校正值都取“中等”值。運用第十三章描述的算法。答：總計：32*4+60*5+24*4+8*10+2*7=618FP=618*[0.65+0.01*3*14]=66119.8利用19.2.3節(jié)中給出的表格，基于每行代碼具有的功能性，提出一個反對運用匯編語言的論據(jù)。再參考該表，探討為什么C++比C更好？答：用匯編語言實現(xiàn)一個功能點須要的行數(shù)在91到694之間平均337行，這幾項在表中都是最大的，一些行業(yè)分析師稱：每天無論運用任何語言的程序員都交出相同數(shù)量的調(diào)試代碼，假如開發(fā)一個項目真用了匯編語言那將比用其它語言花費更多的時間，以上比較方法可以用到C和C++得比較。19.9用于限制影印機的軟件須要32000行C語言代碼和4200行Smalltalk語言代碼。估算該影印機軟件的功能點數(shù)。答：用C語言=162LOC/FP用Smalltalk=26LOC/FP所以32,000/162+4,200/26=197.53+161.54=359FP(近似值)19.10在一個項目結(jié)束時，