本文轉載：軟件工程 實踐者的研究方法 中文題答案_/1的博客-CSDN博客?+ 新添加的的幾個答案

Solutions: CHAPTER 5: AGILE DEVELOPMENT
5.1) One situation in which one or more of the four “values“ could get a software team into trouble
would be Responding to change over following a plan. In many situations, wc no longer arc able to
define requirements fully before the project begins. Software engineers must be agile enough to
respond to a fluid business environment or else they might land up in trouble.

5.2) Agility can be apDlied to any software process. However, to accomplish this, it is
essential that〔he process be designed in a way that allow導 the project team lo adapi
tasks and to streamline them, conduct Dlanning in a way ihat understands the fluidity of
an agile development apinoach, eliminate all but the most essential work products and
keep them lean, and enyhasize an incremenlal delivery strategy ihat gets working
software 1。the customer as raDidly as feasible for the product type and uperaticnal
environment.

5.5) One more ''agility principle** that would help a software engineering team become even more
maneuverable would be, “A team should know whose skills suit a particular project, and get these
people on their project, for soHwarc development to become more effective", and ''Communication
is the key, the consumer and developer should constantly be communicating even if they arc
geographically sq)aratc(L they can web talk*'.

5.8) Most agile process models recommend fece-to-face communication. Yet today, members of a
software team and their customers may be geographically separated from one another in that case
Communication is the key, the consumer and developer should constantly be communicating even
if they arc geographically separated, they can wcbtalk or talk over the phone every now and then or
write emails, use chatting as the, means or a medium of conference call communication where 2
and more people can talk lo each other at the same time.

解決方案：第5章：敏捷發展

5.1）四個“值”中的一個或多個可能使軟件團隊陷入困境的情況將是根據計劃應對變化。在許多情況下，我們不再能夠在項目開始之前充分定義需求。軟件工程師必須足夠敏捷應對多變的商業環境，否則他們可能會陷入困境。

5.2）敏捷性可應用于任何軟件過程。然而，為了實現這一點，至關重要的是，設計過程的方式應允許項目團隊調整任務并使其合理化，以理解敏捷開發流程的流動性的方式進行規劃，消除除最基本的工作產品之外的所有工作產品，并保持其精益求精，并制定一個增加交付策略，即在產品類型和上層環境下，盡可能快速地向客戶提供工作軟件。

5.5）還有一個“能力原則”可以幫助軟件工程團隊變得更具可操作性，那就是“團隊應該知道誰的技能適合特定項目，并讓這些人參與他們的項目，以便軟件開發變得更有效”，以及“溝通”關鍵是，消費者和開發者應該不斷溝通，即使他們是他們可以在網上聊天。

5.8）大多數敏捷流程模型都建議面對面交流。然而，如今，軟件團隊的成員和他們的客戶可能在地理上彼此分離，在這種情況下，溝通是關鍵，消費者和開發人員應該不斷地溝通，即使他們在地理上是分離的，他們可以時不時地通電話或打電話，或者寫電子郵件，電話會議通信的手段或媒介，其中2人或更多人可以同時彼此交談。

6.6) There can be more than one right answer for each scenario, depending on how the students
perceive the products that are being built in each environment.

6.7) Agile teams are self-organizing and may change its organizational structure during diflerent
phases of the project iifetime.

6.10) The cloud has the potential to make evolving software work products and artifacts available
to team members and stakeholders instantly. This can help make version control and acceptance
testing activities more eHicient.

6.12) Distance can make it harder to get in touch with team members (c.g. there may be 12 or
more hour diflerence in time of day). Team members living in difterent countries have diflerent
experiences, diflerent cultural expectations, and may speak difierent languages. Coordination
efforts become paramount in importance to the success of the project. Effective communication
requires a message to be sent, to be received, and to be responded to. Any one of this points of
future can prevent cflective exchange of information among team members and stakeholders.

6.6）根據學生的方式，每個場景可以有多個正確答案感知每個環境中正在構建的產品。

6.7）敏捷團隊是自組織的，可能會在變化期間改變其組織結構項目的各個階段。

6.10）云具有使不斷發展的軟件工作產品和工件可用的潛力立即發送給團隊成員和利益相關者。這有助于進行版本控制和接受測試活動更加高效。

6.12）距離會使與團隊成員聯系更困難（例如，可能有12人或一天中的時間差更大）。生活在不同國家的團隊成員不同的文化期望，可能會說不同的語言。協作努力對項目的成功至關重要。有效溝通需要發送、接收和響應消息未來可能會阻礙團隊成員和利益相關者之間的選擇性信息交流。

第一章?

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

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

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

1.3針對1.1節提出的5個問題，請給出你的答案，并與同學討論。 答:軟件需要如此長的開發時間:?

a)設施不上線?

b)開發工具并不如預期般運作?

c)客戶提出的新要求，需要重新設計和返工?

d)產品依賴于政府的規定，被意外更改。?

e)嚴格的要求，與現有系統的兼容性需要超過預期更多的測試，設計和實現。 f)多個操作系統下運行的任務需求比預期需要更長的時間。?

g)軟件項目風險管理比預期需要更多的時間。?

h)依賴的技術仍處于開發階段，從而延長日程安排。?

開發成本高:?

a)比當時預期低得令人無法接受的質量，需要進行更多的測試，設計和實施工作。?

b)制定了錯誤的軟件功能需要重新設計和實施。?

c)開發錯誤的用戶界面，而導致重新設計和實施。?

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

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

a)產品依賴于政府監管，意外而改變。?

b)產品技術標準草案，會意外更改。?

c)有時會在項目后期添加新的開發人員。?

d)因為團隊內的沖突有時會導致溝通不暢，而產生糟糕的設計。?

e)破壞高效調度產生的項目管理成果和無效的規劃?

f)有時裝備部件質量差，導致額外的測試，設計和集成工作和管理額外的客戶關系。?

軟件開發和維護的過程仍舊難以度量:?

a)有時該項目的目的是不明確。?

b)有大量的業務所涉及的風險。?

c)如果產品內置沒有裝好。?

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

e)進行維護檢查的時間。?

f)在整個軟件開發過程中要徹底組織項目團隊。?

1.4在交付最終用戶之前，或者首個版本投入使用之后，許多應用程序都會有頻繁的變更。為防止變更引起軟件退化，請提出一些有效的解決措施。 答:許多現代應用程序在他們呈現給最終用戶之前和第一個版本別使用后經常改變，以下幾個方面來阻止軟件惡化:?

a)收集所需的信息。?

b)設計師和客戶定義軟件的總體目標。?

c)識別已知的需求。?

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

f)其他人承擔技術任務?

g)文件應該被及時制定出來，在文件中應該有標準定義和機制建立。 h)完成某一特定階段的審查工作。?

i)每一個關鍵團隊成員應該配有一個后備人員?

j)檢查規避風險的步驟是否應用正確?

k)對未來的風險分析中檢查是否有必要收集必要的信息。?

1.5思考1.1.2節中提到的7個軟件分類。請問能否采用一個軟件工程方法，應用于所有的軟件分類,并就你的答案加以解釋。?

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

1.6圖1-3中，將軟件工程三個層次放在了“質量關注點”這層之上。這意味著在整個開發組織內采用質量管理活動，如“全面質量管理”。仔細研究，并列出全面質量管理活動中關鍵原則的大綱。?

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

1.7隨著軟件的普及，由于程序錯誤所帶來的公眾風險已經成為一個愈加重要的問題。設想一個真實場景，由于軟件錯誤而引起“世界末日”般重大危害(危害社會經濟或是人類生命財產安全)。?

答:確實有很多現實生活中的情況來選擇，例如，軟件錯誤，造成了重大的電話網絡失敗。?

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

1.8用自己的話描述過程框架。當我們談到框架活動適用于所有的項目時，是否意味著對于不同規模和復雜度的項目，可應用相同的工作任務,請解釋。 答:過程框架適用于所有的項目，在相同的工作任務，適用于所有項目，無論其規模大小或復雜性。一個過程框架涉及大量的與客戶溝通來收集需求;這個活動建立了一個軟件工程工作計劃。它涉及到創建模型，這將有助于開發人員

了解顧客的要求從而進行設計。從而涉及構建(代碼生成和錯誤測試)。最后，它提供了基于評價的反饋。?

1.9普適性活動存在于整個軟件過程中，你認為他們均勻分布于軟件過程中，還是會集中在某個或者某些框架活動中,?

答:傘活動在整個軟件過程中發生，它們被均勻地應用在整個過程中，分析還包含一系列的工作任務(例如需求收集，制定，協商規范和驗證)，一個過程框架有一組傘被應用在整個軟件過程活動中。這些活動包括:軟件項目跟蹤和控制，風險管理，軟件質量保證，和正式的技術審查，測量，軟件配置管理，可重用性管理和工作產品的制作和生產。?

1.10在1.5節所列舉的神話中，增加兩種軟件神話，同時指出與其相對應的真實情況。?

答:沒有標準答案(例如測試可以解決所有的程序錯誤)。?

第二章?

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

答:a)設計人員詢問用戶:?

產品滿意嗎或者它需要重新設計或返工嗎,?

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

有新要求的需要嗎,?

該產品比估計的大嗎,?

與預期的相比模塊需要更多的測試，設計和實行工作來糾正嗎,?

b) 用戶詢問設計者的問題:?

范圍明確嗎,?

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

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

特定領域的軟件產品比平時的花費更多的時間嗎,?

該模塊是否需要更多的設計測試,?

c)用戶對將要構建的軟件自問的問題:?

軟件產品的范圍和目的是什么?

該產品比估計的大嗎,?

有優秀的人可用嗎,?

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

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

d)設計者對于軟件產品和建造該產品采取的軟件過程自問的問題: 范圍和目的文件是什么,?

要使用什么樣的工具,?

有什么目標和規避風險的優先事項,?

對風險分析，識別，估計，評價和管理會有什么樣的步驟,?

2.2為溝通活動設計一些列的動作，選定一個動作作為其設計一個任務集。 答:任務交流活動設置:任務組將定義實際的工作需要，以完成一個軟件工程的行動。這些都是對于通信的活動:?

a)利益相關者對項目做一個列表。?

b)邀請所有利益相關者的非正式會議。?

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

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

e)他不確定的優先級的要求和要注意的地方。?

這些任務可能是一個復雜的軟件項目，然后，他們可能包括:?

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

b)要建立一個股權持有人要求的修訂清單。?

c)使用質量功能展開技術來滿足需求。?

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

e)討論驗證系統的方法。?

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

模式名:利益相關者的需求沖突。?

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

初始背景:(1)利益相關者已確定(2)利益相關者和軟件工程師已經建立了協作通信(3) 軟件要解決的主要問題由軟件開發團隊已建立。(4)對已開發的項目范圍，基本的業務需求和項目的限制有了初步的了解。?

問題:對正在開發的軟件，利益相關者的需求出現了相互的矛盾。 解決辦法:所有的利益相關者被要求區分需求的優先級，暫時保住利益相關者的優先級最高或投票的最多的需求從而解決這一問題。?

結果:由利益相關方的確定的需求優先順序列表來指導軟件開發團隊構件軟件初始模型。?

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

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

2.5詳細描述三個適用于采用瀑布模型的軟件項目。?
答:適合瀑布模型的項目例如數據結構，軟件架構，程序的細節和接口表征的對象。?

2.6詳細描述三個適用于采用原型模型的軟件項目。?
答:相對容易的原型模型幾乎總是涉及人機交互和/或復雜計算機圖形軟件應用程序，有時適合原型模型是某些類別的數學算法，命令驅動系統和其他應用在沒有實時交互時結果可以很容易地檢查。難以用原型模型的應用程序，包括控制和過程控制功能許多種類的實時應用程序和嵌入式軟件。?

2.7如果將原型變成一個可發布的系統或產品，應該如何調整過程。?
答:如果將原型變成一個可發布的系統或產品，軟件工程師和客戶需要滿足和定義軟件的總體目標，識別已知的任何要求，對整體輪廓進一步的強制定義。原型作為一種機制，用于識別軟件需求。如果一個工作原型被建立了，開發商會試圖利用現有的程序片段或應用工具(例如，報表生成器，窗口管理等)使工作方案，可以快速生成。?

2.8詳細描述三個適于采用增量模型的軟件項目。?
答: 每一個線性序列產生的“增量”交付的軟件，例如字處理軟件開發使用增量范式可能會提供基本的文件管理，編輯和文件制作功能在第一增量，更復雜的編輯和文件制作能力在第二增量;拼寫和語法檢查在第三增量，先進的頁面布局能力在第四增量。任何增量的處理流程 可以納入原型范式。增量發展是特別有用當人員無法在經營期限為一個已成立的項目做完美的實施。?

2.9當沿著螺旋過程流發展的時候，你對正在開發或者維護的軟件的看法是什么,?
答:隨著工作的螺旋向外移動，產品走向一個更完整的狀態，執行工作的抽象層次減少了。?

2.10可以合用幾種過程模型嗎,如果可以，舉例說明。?
答:過程模型可以合用，每個模型都有個有點不同的處理流程，但都執行相同的通用框架活動集:溝通，規劃，建模，施工和交付/反饋。例如線性順序模型可以作為一個有用的過程模型，在被固定的情況下，要求工作以線性的方式繼續進行，直至完成。在這情況下，開發者可能無法確定一種算法的效率，一個操作系統的適應性或應采取的人機交互的形式。在這之中，以及許多其他場合原型模型可以提供最好的辦法。在其他情況下，以漸進的方式可能是有意義的和螺旋模型的流動可能是有效率，特殊過程模型具有許多的一個或多個傳統的特性。?

2.11協同過程模型定義了一套“狀態”，用你自己的話描述一下這些狀態表示什么，并指出他們在協同過程模型中的作用。?
答:簡而言之，并發進程模型假定不同的部分項目會有所不同階段的完整性，因此，不同的軟件工程活動都被同時執行。目前的挑戰是管理的并發，并能夠評估該項目的狀態。?

2.12開發質量“足夠好”的軟件，其優點和缺點是什么,也就是說，當我們追求開發速度勝過產品質量的時候，會產生什么后果,?
答:開發質量“足夠好”的軟件可能會碰到死亡線(截止時間)，但質量會是比較好的。當追求開發速度超過了產品的質量，這可能會導致許多缺陷，該軟件可能需要更多的測試，設計和實施工作。需求定以的不是很清楚，可能需要不斷地改變。半調子和速度過快開發都可能導致無法檢測到重大的項目風險。質量太差可能導致過多的質量問題和頻繁的返工。?

2.13詳細描述三個適于采用基于構件模型的軟件項目。?
答:我會建議推遲這個問題直到“軟件過程改進”這一章。?

2.14我們可以證明一個軟件構件甚至整個程序的正確性，可是為什么并不是每個人都這樣做,?
答:這是可能的用數學技術來證明軟件組件，甚至整個程序的正確性。然而，對于復雜的程序，這是一個非常耗時的過程。用詳盡的測試是不可能證明任何不平凡的程序的正確性，?

2.15統一過程和UML是同一概念嗎,解釋你的答案。?
答:UML提供了必要的技術支持和面向對象的軟件工程實踐。但它并不提供流程框架來指導項目團隊，在他們的技術應用中。在近幾年中，雅各布森， Rumbaugh和Booch制定的統一過程中框架使用UML的面向對象的軟件工程。今天，統一的流程和UML被廣泛應用于各種面向對象的項目。?

第777777章?

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

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

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

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

4.5最好的協商是爭取“雙贏”,這會使你成為是一位談判大師。這些初期步驟的成功實施可以達到一個雙贏的結果，這是繼續開展后續的軟件工程活動的關鍵。?

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

誰是這項工作的最初請求者,?

誰將使用該解決方案,?

成功的解決方案將帶來什么樣的經濟收益,?

對于這個解決方案你還需要其他資源嗎,?

4.7-4.9答案略。?

4.10用例圖描述了參與者所能觀察到模型圖。用例圖鼓勵系統的功能視圖應該轉換為面向對象的視圖。在許多情況下，為了提供更多的相互作用，用例圖需要做更詳細的闡述。?

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

4.13最好的協商是爭取“雙贏”的結果，即利益相關者的“贏”在于獲得滿足客戶大多數需要的系統或產品，而作為軟件團隊一員的“贏”在于按照實際情況、在可實現的預算和時間期限內完成工作。?

4.14當需求確認解釋了一個錯誤時，每個需求有一個問題清單。之后會有評審小組尋找它。確認需求的評審小組包括軟件工程師、客戶、用戶、和其他利益相關者，他們在檢查系統規格說明，查找內容或解釋上的錯誤，以及可能需要進一步解釋澄清的地方、丟失的信息、不一致性(這是建造大型產品或系統時遇到的主要問題)、沖突的需求或是不可實現的(不能達到的)需求。?

第五章?

5.1有沒有可能在分析建模創建后立即開始編碼,解釋你的答案，然后說服反方。 答:分析模型作為領域對象的設計和結構的基礎服務。在定義了對象和屬性后，就可以開始進行編碼，也就知道了對象之間的關系。?

5.2 一個單憑經驗的分析原則是:模型“應該關注在問題域或業務域中可見的需求”。在這些域中哪些類型的需求是不可見的,提供一些例子。?

答:正如我們所知道的，在開始階段很可能沒有完整的需求規范。客戶可能不是非常精確地確定他們的所有需求。開發者也沒有把握使用一個具體的方法來正常的完成系統的功能和性能。為了需求分析和建模，不傾向使用迭代的方法。分析師所將認識到的東西進行建模，并使用此模型作為軟件增量的設計的基礎。軟件增量作為流程迭代的一部分被制作出來。在這些領域中，需求的類型是不可見的，可能因為一些功能必須在系統中實現，系統展示的行為是什么，屬性定義的接口有哪些，應用的約束有哪些,?

5.3 域分析的目的是什么,如何將域分析與需求模式概念相聯系, 答:域分析是持續的軟件工程活動，不與任何的軟件項目相關聯。它與需求模式的概念相聯系。域分析是通過一系列活動進行表征的過程。這些活動從識別域開始，以描述域中對象和類的規范為結束。?

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

答:如果沒有圖6.3所示的4大元素，是不可能開發出一個有效的分析模型。分析模型作為域對象的設計和建造的基礎。?

5.5 構建如下系統中的一個:?

a你所在大學基于網絡的課程注冊系統。?

b一個計算機商店的基于Web的訂單處理系統。?

c一個小企業的簡單發票系統。?

d內置于電磁灶或微波爐的互聯網食譜。?

選擇你感興趣的系統開發一套試題關系圖并說明數據對象、關系和屬性。 答:需要強調的是，所有的數據對象和關系一定客戶可見的。為了確認屬性正確地反映出系統的需求，屬性應該被檢查。(無固定答案)?

5.6-5.9答案略。?

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

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

第六章?

6.1 對于需求分析，結構分析與面向對象策略有何本質區別,?

答:結構分析，考慮把數據作為分離實體的變形的數據和過程。數據目標是被使用它們已被定義的屬性和關系建模的。過程操作數據目標是被使用它們在系統中的數據流向建模的。面向對象分析，集中于類的定義和它們合作對用戶需求所帶來的效果的方式。?

6.2 在數據流圖中，一個箭頭表示控制流還是其他,?

答:DFD數據目標是用有標簽的箭頭所表示的。?

6.3 什么是“信息流連續性”,當重新定義一個數據流時，如何應用它, 答:數據流動連續性意味著在同一等級中的輸入和輸出必須和它們的精確等級相同。?

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

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

6.5 什么是控制規格說明,?

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

6.6 PSPEC和用例是同一事物嗎,如果不是，請解釋區別。?

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

6.7 表示行為建模時有兩種不同“狀態”類型，它們是什么,?

答:被動狀態展現出目標屬性的正確情況。主動狀態指明了目標在轉化或執行過程中的正確情況。?

6.8 如何從狀態圖區分順序圖,它們有何相似之處,?

答:狀態圖描述了系統的狀態并且展現了事件如何影響系統狀態。?

順序圖指明了事件如何引起目標的遷移。?

6.9——6.10答案略。?

第七章?

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

7.2軟件設計的目的是運用一系列的原則、概念和實踐導致高質量體系或產品的發展。設計的目標是創建一個可以正確地實現所有客戶需求并有好的用戶體驗的軟件模型。

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

7.4為了開發一個完整的設計模型，軟件團隊反復地開發每個模塊的元素。每次迭代提供額外的細節并且細化。此外，設計任務應用于一個項目可能不同于他們應用其他項目。團隊必須適應一個通用的任務集去滿足產品，人和項目的需

要。質量的評估在有被修改的錯誤的組件級的設計任務集。任務集在章節中給出。?

7.5略?

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

7.7略?

7.8分離關注點涉及通過將其分成單獨解決的子問題解決一個復雜的問題，一個問題的不同部分是相互結合的方式，給與不同的考慮，而不是合并考慮更復雜的情況。高度耦合的問題表現出這一特征。然而，問題的部分繼續組合，因為信息量超過了解一個人的能力不能無限期地進行下去，因此，當問題非真，模塊化可以修改，但不能消除。?

7.9在某些時間關鍵應用程序下,可能需要單塊集成軟件。然而,如果軟件是模塊化實現，設計可以而且應該實現的。“模塊”是內聯編碼。?

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

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

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

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

細化1:

寫出大寫金額總數。

細化2:

寫出大寫金額數的程序:

驗證金額數是否在允許范圍內;

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

,用α來表示金額數，寫出來;

結束寫出大寫金額數程序

細化3:

寫出大寫金額數的程序:

檢查是否還有未打印的支票，如有進入下面的循環

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

如果大于打印“金額數太大”的錯誤信息

否則確定過程標志符為1。

結束判斷。

當過程標志符為1和有效數字存在的話，進入下面的循環:

確定最高有效位;

設置對應阿爾法短語;

劃分來確定整數值;

連接部分α字符串;

7.13略?

7.14不，重構是一種不改變代碼的外部行為和其功能而改善軟件產品的內部質量的過程。他可能是提高了一個函數的處理速度或者在另一個系統中起到簡化組件的作用。?

7.15四個要素的設計模型:?

設計模型的四個元素:?

數據/類設計——建立由分析轉化的基于類內元素的類模型和按數據結構要求實現的軟件。?

結構設計——定義大體軟件元素結構件的關系。?

接口設計——描述軟件元素,硬件元素和用戶終端通信。?

組件等級設計——建立由軟件組件的程序描述中的軟件結構所定義的元素結構變形。?

第八章?

8.1用一個房屋或建筑結構作比喻，與軟件體系結構作對照分析。經典建筑與軟件體系結構的原則有什么相似之處,又有何區別,?

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

8.2舉出2到3個例子，說明8.3.1節中提到的每一種體系結構風格的應用。 答:數據中心體系結構:航空訂票系統;圖書館目錄系統;賓館訂閱系統。 數據流結構:任何工程或科學中主要功能是計算的應用程序。?

調用和返回結構:任何I-P-O申請。?

面對對象的體系結構:基于GUI的應用程序;任何面向對象的應用程序 。 分層體系結構:應用功能必須從底層操作系統或網絡詳細信息分離的應用程序。客戶端服務器軟件通常是分層的。?

8.3 8.3.1節中提到的一些體系結構風格具有層次性，而另一些則沒有。列出每種類型。沒有層次的體系風格如何實現,?

答:

層次:數據流，調用返回層。?

非層次:數據中心，面向對象。?

非分層體系結構可能是應用面對對象和驅動編程技術的最好實現。?

8.4 在軟件體系結構討論中，經常會遇到體系結構風格、體系結構模式及框架(本書中沒有討論)等術語。研究并描述這些術語之間的不同。?

答:許多人把建筑模式和建筑風格等價定義(把通用系統模型作為程序設計的起始點)，盡管模式往往不太廣泛。一個框架可能會被一些人定義為一組提供了一個通用的解決問題方案的類，被解決的問題可以被細化到創建一個應用程序。?

8.5 選擇一個你熟悉的應用，回答8.3.3節中對于控制與數據提出的每一個問題。 答:答案不固定。?

8.6 研究ATAM([Kaz98])并對8.5.1節提出的6個步驟進行詳細討論。 答:答案不固定。?

8.7 如果還沒有完成習題5.6，請先完成它。使用本章描述的設計方法開發PHTRS的軟件體系結構。?

答:答案不固定。?

8.8 使用數據流圖和過程說明，描述一個有清楚變換流特征的計算機系統。定義流邊界并使用8.6.1節描述的技術將DFD映射到軟件體系結構中?

答:答案不固定。?

第九章?

9.1構件級設計定義了數據結構、算法，界面特性以及分配給每個軟件構件的通信機制。在面向對象語言中(JAVA或Smalltalk)構件為類或對象。在傳統語言(C或Fortran)中構件式函數或操作過程。在混合語言中(如C++)構件可能是函數或類。?

9.2像面向對象的構件一樣，傳統軟件構件是由分析模型所導出的。然而在這種情況下，導出構件是以分析模型中面向數據流元素作為基礎。數據流圖的最低層的每個變換都被映射為某一層上的模塊。控制構件(模塊)位于層次結構(體系結構)頂層附近，而問題域構件則傾向位于層次結構的底層。為了獲得有效的模塊化，在構建細化的過程中采用了功能獨立性的設計概念。?

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

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

9.5構件級設計中面向對象系統的上下文中，內聚性意味著構件或者類只封裝那些相互關聯密切，以及與構件或者類自身有密切關系的屬性和操作。高內聚的構件會與其他構件提供的服務“絕緣”，從而使其實施與維護更加容易。

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

9.7外部耦合發生在組件通信或與基礎設施組件(如。、操作系統功能、數據庫功能、通信功能)。雖然這種類型的耦合是必要的,它應該是局限于一小部分系統組件或類。軟件必須在內部和外部溝通。因此,耦合是一個不爭的事實。然而,設計師應盡可能減少耦合和理解高耦合的影響不可避免。?

9.8略?

9.9 重構是系統決策集散控制的過程，目的是讓頂層模塊執行控制功能，而底層模塊處理所有輸入，執行和輸出工作。逐步求精是通過連續精化過程細節層次來實現程序的開發。在傳統軟件開發中兩者是很相似的。?

9.10

WebAPP構件定義為以下兩點之一:?

定義良好的聚合功能，為最終用戶處理內容，或提供計算或數據處理 內容和功能的聚合包，提供最終用戶所需的功能。?

9.11略?

9.12略?

9.13略?

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

第十章?

10.1這道題應該不難～許多早期交互式系統都有糟糕的界面。在現代環境下，讓你的學生們注重基于web的應用程序界面。許多web應用程序為了Flash犧牲易用性。?

10.2例子如下:?

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

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

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

10.3例子如下:?

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

當一個web應用程序需要密碼輸入的時候，提供“密碼提示”機制。?

10.4例子如下:?

使用一致的顏色，例如，紅色用作警示信息，藍色用作通知信息; 提供關鍵字驅動的在線幫助。?

10.5答案略。?

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

10.7-10.11答案略。?

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

10.13答案略。?

10.14如果你想要給你的學生一些工作項目表的范例，互聯網是一個很好的可用性調查表的來源(大部分都應該有超過20道的問題，所以你的學生應該需要優先考慮他們的選擇)?

第十四章?

14.1用自己的話描述驗證與確認的區別。兩者都要用測試用例的設計方法和測試策略嗎,?

答:“驗證”是通過嘗試在功能或性能上發現錯誤來保證程序的正確性，“確認”是保證軟件與需求相一致——這也是質量的基本特征。?

14.2列出一些可能與獨立測試組(ITG)的創建相關的問題。IGT與SQA小組由相同的人員組成嗎,?

答:組建ITG(獨立測試組)最常見的問題是獲得并留住人才，除此之外，如果ITG與軟件工程小組的交流組織地不恰當的話，兩組之間可能會產生敵意。最后，ITG有可能太晚接手項目，導致沒有時間完成一個周密測試的計劃和執行。ITG和SQA(軟件質量保證)小組不必是同一組人。ITG只關注測試，SQA小組則需要考慮到質量保證相關的所有方面。?

14.3使用14.1.3節中描述的測試步驟來建立測試軟件的策略總是可行的嘛,對于嵌入式系統，出現哪些可能的復雜情況,?

答:它并不總是能夠進行單元測試的測試環境，完成單元測試的復雜性(如復雜的驅動和存根)可能無法證明效益。集成測試是復雜的通過單元測試的模塊合并計劃的有效性(特別是當這些模塊滯后的時候)。在很多情況下(尤其是嵌入式系統)軟件不能充分進行驗證測試硬件配置外的目標。因此，驗證和系統測試要相結合。?

14.4為什么對具有較高耦合度的模塊進行單元測試,?

答:一個高度耦合的模塊要與其他模塊的數據和其他系統元素進行交互。因此，其功能往往是依賴于這些耦合元件的操作。為了徹底的單元測試這樣一個模塊，耦合因素的功能必須以某種方式模擬。這將會是困難和費時的。?

14.5“防錯法”的概念是一個非常有效的方法。當發現錯誤時，他提供了內置調試幫助:?

a.為防錯發開發一組知道原則。?

b.討論利用這種技術的優點。?

c.討論利用這種技術的缺點。?

答:一個單一的規則涵蓋了多種情況:所有數據在軟件接口(外部和內部)應當經過驗證(如果可能的話)。?

優點:錯誤不會―滾雪球‖——越滾越大?

缺點:需要額外的處理時間和內存(那通常只是一個很小的代價)。?

14.6項目的進度安排是如何影響集成測試的,?

答:完成模塊的可用性的影響順序和戰略整合。項目狀態必須是已知的，可以成功地實現整合規劃。?

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

答:如果一個模塊有3或4個下屬供應數據模塊的一個有意義的評價是至關重要的，沒有―聚類‖所有的模塊作為一個單元，它可能無法進行單元測試。?

14.8誰應該完成確認測試——是軟件開發人員還是軟件的使用者，說明你的理由。?

答:開發商，如果客戶驗收測試計劃。開發人員和客戶(用戶)如果沒有進一步的測試計劃。一個獨立的測試組可能是這里最好的選擇，但這不是一個選擇。?

14.9為本書討論的safehouse系統開發一個完整的測試策略，并以測試規格說明的方式形成文檔。?

答:略?

14.10作為一個班級項目，為你的安裝開發調試指南。這個指南應該提供面向語言和面向系統的建議。這些建議是通過總結學校學習過程中所遇到的挫折得到的。從一個經過全班和老師評審過的大綱開始，并在你局部范圍內將這個指南發布給其他人。?

答:略?

第十五章?

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

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

15.2設計并實現15.1描述的程序(適當使用錯誤處理)。從該程序中導出流圖并用基本路徑測試方法設計測試，以保證程序中的所有語句都被測試到。執行測試用例并顯示結果。?

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

15.3你能夠想出15.1.1節中沒有討論的其他測試目標嗎,?

答:除了那些目標之外還有:?

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

b) 一個成功的測試發現文件錯誤;?

c) 一個成功的測試發現接口問題;?

d) 一個成功的測試驗證了程序結構，了解數據結構，界面設計和程序設計; e) 一個成功的測試，建立了一個進入一個測試案例數據庫，以后可以用于回歸測試。?

15.4選擇一個你最近設計和實現的構建。設計一組測試用例，保證利用基本路徑測試執行所有語句。?

答:略?

15.5-15.8

答:進行一些拓展，這些問題可以被指定為一個長期的項目。?

15.9至少給出三個例子，在這些例子中，黑盒測試能給人“一切正常”的印象，而白盒測試可能發現錯誤。再至少給出三個例子，在這些例子中白盒測試能給人“一切正常”的印象，而黑盒測試可能發現錯誤。?

答:對于特定的輸入，一個內部發生的錯誤導致:?

1) 不恰當的數據被設在一個全局數據域里;?

2) 不恰當的標記將在隨后進行的一系列測試中被測試;?

3) 不恰當硬件控制，只可能在系統測試時被發現;但是卻產生了正確的輸出。?

15.10不，即使窮舉測試(如果可能的話)也不能發現軟件說明書中的性能問題和錯誤。在這種情況下需要同時考慮輸入和輸出的等價類。對每一個類來說，學生應當根據數值范圍，集合的元素，系統命令等劃定邊界。這可以作為筆試以及一些著名應用GUI的測試用例的素材?

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

第十六章?

16.1用自己的話，描述為什么在面向對象系統中，類是最小的合理測試單元。 答:類封裝了數據以及處理數據的操作。由于數據和操作被打包成一個整體，一個一個地測試方法沒有作用，不能發現與消息傳送，職責和協作相關的錯誤。?

16.2若現有類已進行了徹底的測試，為什么我們必須對從現有類 實例化的子類進行重新測試,我們可以使用為現有類設計的測試用例么,?

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

16.3為什么―測試‖應該從面向對象分析和設計開始,?

答:在之后的開發過程中，面向對象分析和設計模型提供了大量與系統結構和行為相關的信息，因此，在生成代碼之前，這些模型必須經過嚴格的審查。所有面向對象的模型應當在模型的語法，語義以及語用論的上下中經過正確性，

完整性，一致性的測試(包括技術評審)。這些評審有可能省去很多不必要的工作和修改(錯誤越早發現，維護的成本越低)。?

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

答:答案會有不同?

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

16.6將隨機測試和劃分方法運用到設計SafeHome系統時定義的3個類。產生展示操作調用序列的測試用例。?

答:答案會有不同?

16.7運用多類測試及從SafeHome設計的行為模型中生成的測試。?

答:答案會有不同?

16.8運用隨機測試、劃分方法、多類測試及16.5節和16.6節所描述的銀行應用的行為模型導出的測試，再生成另外生成4個測試。?

答:答案會有不同?

第十八章?

18.1基于本章給出的信息和自己的經驗，列舉出能夠增強軟件工程師能力的“十條戒律”。即，列出10條指導原則，使得軟件人員能夠在工作中發揮其全部潛力。?

答:?

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

(2)你要注重質量。?

(3)你要傾聽客戶。?

(4)你要了解問題?

(5)你要對一個工作過程不斷的重復。?

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

(7)你要測量產品，過程和你自己。?

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

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

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

18.2 SEI的人員能力成熟度模型定義了培養優秀軟件人員的“關鍵實踐域”。你的老師將為你指派一個關鍵實踐域，請你對它進行分析和總結。?

答:略。?

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

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

不同的人:(1)一個通信部門的一些業務功能的服務。(2)一個軟件開發團隊服務營銷的需求。(3)承包商建立的客戶的規格。?

18.4高級管理者所做的決策會對軟件工程團隊的效率產生重大影響。也描述3種他們是不同人的情況。?

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

18.5溫習Weiberg的書[Wei86]，并寫出一份2-3頁的總結，說明在使用MOI模型時應該考慮的問題。?

答案:略。?

18.6在一個信息系統組織中，你被指派為項目經理。你的工作是開發一個應用程序，該程序類似于你的團隊已經做過的項目，只是規模更大而且更復雜。需求已經由用戶改寫成文檔。你會選擇哪種團隊結構,為什么,你會選擇哪(些)種軟件過程模型,為什么,?

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

18.7你被指派為一個小型軟件產品公司的項目經理。你的工作是開發一個有突破性的產品，該產品結合了虛擬現實的硬件和高超的軟件。因為家庭娛樂市場的競爭非常激烈，完成這項工作的壓力很大。你會選擇哪種團隊結構,為什么,你會選擇哪種過程模型,為什么,?

答:隨機式范型的團隊結構可能是唯一可行的選擇，給出了模糊的要求和工作性質的實驗。應該使用原型開發方法或者一個曾量的過程模型。?

18.8你被指派為一個大型軟件產品公司的項目經理。你的工作是管理該公司已被廣泛使用的字處理軟件的新版本的開發。由于競爭激烈，已經規定了緊迫的最后期限，并對外公布。你會選擇哪種團隊結構,為什么,你會選擇哪些軟件過程模型,為什么,?

答:一個開放式范型團隊結構可能是最好的，給定的時間壓力和熟悉的工作(然而，封閉的方法范式團隊可能也很好)。一個曾量過程模型被推動這項工作性質的最后期限所指明。?

18.9在一個為基因工程領域服務的公司中，你被指派為軟件項目經理。你的工作是管理一個軟件新產品的開發，該產品能夠加速基因分類的速度。這項工作是面向研究及開發的，但其目標是在下一年度內生產出產品。你會選擇哪種團隊結構,為什么,你會選擇哪些軟件過程模型,為什么,?

答:一個隨機式范型可能是最好的，是因為這項工作是實驗性的，且有一個企業的最后期限。另一種可能性是使用一個開放式范型的團隊結構。一個曾量過程模型和進化過程模型可以用于推動給予限期的這項工作。?

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

分數分析應用程序將獲得所有本科和研究生的學分課程的成績和在某一學期課程注冊數據庫。分數分析應用程序會讀每一門課程的所有等級和計算平均成績，使用的數值范圍在A = 4和其他等級分配值來作為等級值存到uc29-1文檔。本程序會打印一個報告顯示每門課的教師和平均成績。這個報告可能會按平均成績或者教師等其他類似的特征排序。本程序可能會運行在WindowsVista操作系統下。?

18.11給出18.3.2節中討論的頁面布局功能的第一級功能分解。?

答:?

一個簡單的分解:?

頁面布局?

定義頁面參數?

分配文本區域?

分配圖形區域?

強調定義(線，著色等)?

輸入/導入文本?

輸入/導入?

編輯文本?

編輯圖形?

出頁/導出頁面?

最終頁面布局?

第十九章?

19.1用自己的話描述過程度量和項目度量之間的區別。?
答:過程度量是用來對設計和建造計算機軟件的活動進行評估(為了在后續項目提高這些活動)。?
項目度量是用來評估軟件項目的狀態。?

19.2為什么有些軟件度量是“私有的”,給出3個私有度量的例子，并給出3個公有度量的例子。?
答:當待評估的特征無法被直接測量時一種間接的的測量方法將被使用，例如,“質量”不能被直接測量所以只能測量軟件其他的特征，軟件的很多度量工作都間接的，因為軟件不是一個有形的可以用直接測量的實體。例子?
能直接度量的物體?
紙的數量?
人的數量?
不同文件的數量?
不能直接度量的物體?
可讀性(利用模糊指數)?
完整性(計算你收到的‖服務臺‖問題的數量)?
可維護性 (定時改變文檔)

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

19.4Grady提出了一組軟件度量規則，你能在19.1.1節所列的規則中在增加3個規則嗎,?
答:軟件度量的額外規則:?
不找完美的指標……它不存在。?
保證測量的一致性，避免比較不同的事物。?
注重質量，這是最重要的。?

19.5產品交付之前，團隊A在軟件工程過程中發現了342個錯誤，團隊B發現了184個錯誤。對于項目A和B，還需要做什么額外的測量，才能確定哪個團隊能夠更有效地排除錯誤,你建議采用什么度量能有助于做出判定,那些歷史數據可能有用,?
答:兩個團隊應該事先決定好要開發的軟件的大小和功能，例如，errors/FP可以提供一個規范化的評估方法。此外，在兩個團隊的軟件開發過程中一個度量標準例如DRE可以提供一個對SQA的效率指標。?

19.6給出反對將代碼行作為軟件生產率度量的論據。當考慮幾十個或幾百個項目時，你說的情況還成立嗎,?
答:LOC的作用不大是因為它的獎勵―verbose‖計劃，同時他也很難用在可視化編程中，4GLs，代碼生成器，或其他的代碼生成器4gts的發展正在遠離3gls

19.7根據下面的信息域特性，計算項目的功能點值:?
用戶人數:32
用戶輸出數:60
用戶查詢數:24
文件數:8
外部接口數:2
假定所有的復雜度校正值都取“中等”值。使用第十三章描述的算法。?
答:?
總計: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節中給出的表格，基于每行代碼具有的功能性，提出一個反對使用匯編語言的論據。再參考該表，討論為什么C++比C更好,?
答:用匯編語言實現一個功能點需要的行數在91到694之間平均337行，這幾項在表中都是最大的，一些行業分析師稱:每天無論使用任何語言的程序員都交出相同數量的調試代碼，如果開發一個項目真用了匯編語言那將比用其它語言花費更多的時間，以上比較方法可以用到C與C++得比較。?

19.9用于控制影印機的軟件需要32000行C語言代碼和4200行Smalltalk語言代碼。估算該影印機軟件的功能點數。?
答:?
用C語言 = 162 LOC/FP
用Smalltalk = 26 LOC/FP
所以 32,000/162 + 4,200/26 = 197.53 + 161.54 = 359 FP (近似值)

19.10在一個項目結束時，確定在建模活動中發現了30個錯誤，在構造活動中發現了12個可以追溯到建模活動中沒有發現的錯誤。那么，建模活動的DRE是多少,?
答:DRE = E / (E + D) = 30 / (30 + 12) = 30 / 42 = 0.71.(近似值)

19.11軟件團隊將軟件增量交付給最終用戶。在第一個月的使用中，用戶發現了8個缺陷。在交付之前，軟件團隊在正式技術評審和所有測試任務中發現了242個錯誤。那么在使用一個月之后，項目總的缺陷排除效率(DRE)是多少,?
答:DRE = E / (E + D) = 242 / (242 + 8) = 242 / 250 = 0.97(近似值)

總結

以上是生活随笔為你收集整理的软件工程-实践者的研究方法第八版(不全)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。