軟件工程第十版課后習題答案(中文版)

第一章概述1.2通用的軟件產(chǎn)品開發(fā)和定制化軟件開發(fā)之間最重要的區(qū)別是什么?這在實踐中對于通用軟件產(chǎn)品的用戶意味著什么?根本區(qū)別在于，在通用軟件產(chǎn)品開發(fā)中，規(guī)范由產(chǎn)品開發(fā)者擁有。對于定制產(chǎn)品開發(fā)，規(guī)范由客戶擁有和控制。這一點的影響是重大的——開發(fā)者可以根據(jù)一些外部變化（例如競爭產(chǎn)品）迅速決定更改規(guī)范，但當客戶擁有規(guī)范時，更改必須在客戶和開發(fā)者之間進行協(xié)商，并且可能會產(chǎn)生合同影響。對于通用產(chǎn)品的用戶，這意味著他們無法控制軟件規(guī)范，因此無法控制產(chǎn)品的演變。開發(fā)者可能會決定包含/排除功能并更改用戶界面。這可能會對用戶的業(yè)務流程產(chǎn)生影響，并在安裝新版本的系統(tǒng)時增加額外的培訓成本。這也可能會限制客戶改變自己業(yè)務流程的靈活性。1.3軟件產(chǎn)品應該具有的4個重要屬性是什么?另外舉出4個可能有意義的屬性。四個重要的屬性是可維護性、可靠性和安全性、效率和可接受性。其他可能重要的屬性可能是可重用性（它是否可以在其他應用程序中重用）、可分布性（它是否可以分布在處理器網(wǎng)絡上）、可移植性（它是否可以在多個平臺上運行，例如筆記本電腦和移動平臺）和互操作性（它是否可以與廣泛的其他軟件系統(tǒng)一起工作）。對4個關鍵屬性的分解，例如可靠性分解為安全性、安全性、可用性等，也是這個問題的有效答案。1.4除了異構性、企業(yè)和社會的變革、可信和信息安全之外，說一說軟件工程在21世紀有可能面對的其他問題和挑戰(zhàn)(提示：想一想環(huán)境)。軟件工程面臨的問題與挑戰(zhàn)眾多，主要包括：開發(fā)節(jié)能系統(tǒng)，以提升其在低功耗移動設備上的適用性，并減少IT設備的整體碳排放。開發(fā)模擬系統(tǒng)的驗證技術，這對于預測和應對氣候變化的程度至關重要。開發(fā)適合多文化背景用戶使用的系統(tǒng)。開發(fā)能夠迅速適應新商業(yè)需求的靈活系統(tǒng)。設計便于外包開發(fā)的系統(tǒng)架構。開發(fā)具有高安全性的系統(tǒng)，能夠抵御各種攻擊。開發(fā)易于最終用戶調(diào)整和配置的系統(tǒng)。探索測試、驗證和維護最終用戶開發(fā)系統(tǒng)的有效方法。1.5參考1.1.2節(jié)討論的應用類型，舉例說明為什么設計和開發(fā)不同類型的應用需要特殊化的軟件工程技術。不同應用類型需要使用不同的開發(fā)技術，原因如下：成本與變更頻率。一些系統(tǒng)（如消費設備中的嵌入式系統(tǒng)）更改成本極高；其他系統(tǒng)則需要頻繁變化以響應需求變化（如業(yè)務系統(tǒng)）。更改成本極高的系統(tǒng)需要進行廣泛的前期分析以確保需求一致性，并進行廣泛的驗證以確保系統(tǒng)符合規(guī)格。這對于快速變化的系統(tǒng)來說并不具成本效益。最重要的“非功能”需求。不同系統(tǒng)對非功能需求的優(yōu)先級不同。例如，飛機中的實時控制系統(tǒng)以安全為主要優(yōu)先級；交互式游戲則以響應性和可用性為優(yōu)先級。用于實現(xiàn)安全的技術不適用于交互式游戲；游戲所需的廣泛用戶界面設計在安全關鍵的控制系統(tǒng)中不需要。軟件生命周期和交付計劃。一些軟件系統(tǒng)的生命周期相對較短（如許多基于網(wǎng)絡的系統(tǒng)），而其他系統(tǒng)的生命周期可達數(shù)十年（如大型指揮和控制系統(tǒng)）。某些系統(tǒng)需要快速交付以便實用。開發(fā)短生命周期、快速交付系統(tǒng)的技術（如使用腳本語言、原型開發(fā)等）不適用于需要長期支持的系統(tǒng)，這些系統(tǒng)需要采用允許長期支持的技術，如設計建模。1.8討論一下職業(yè)工程師是否應該和醫(yī)生或律師一樣頒發(fā)資格證書。這些是可能的討論要點——任何討論都會涉及廣泛的范圍，并觸及諸如職業(yè)操守等其他問題。認證的優(yōu)勢認證向雇主表明具備某種最低水平的能力。認證提升了職業(yè)的公眾形象。認證通常意味著建立和檢查教育標準，因此是一種確保課程質(zhì)量的機制。認證在爭議發(fā)生時意味著責任。認證機構可能被接受為在國家和國際層面代表該職業(yè)的權威認證可能提高軟件工程師的地位，并吸引特別有能力的人進入該職業(yè)。認證的劣勢認證往往導致保護主義，認證成員往往不保護他人免受批評。認證并不保證能力，僅表明在認證時達到了最低標準。認證費用高昂，會增加個人和組織的成本。認證往往會抑制變革。在技術發(fā)展非常迅速的領域，這是一個特別的問題。第二章軟件過程2.1針對以下每個系統(tǒng)，請推薦最合適的可以管理其開發(fā)的基礎的通用軟件過程模型，按照所開發(fā)系統(tǒng)的類型給出你的理由。一個汽車中的防抱死剎車控制系統(tǒng)；一個支持軟件維護的虛擬現(xiàn)實系統(tǒng)；一個準備替換現(xiàn)有系統(tǒng)的大學會計系統(tǒng)；一個交互式的旅行規(guī)劃系統(tǒng)，可以幫助用戶以最小的環(huán)境影響規(guī)劃旅程。1.防抱死制動系統(tǒng)：這是一個安全關鍵系統(tǒng)，因此在實施前需要大量的前期分析。它肯定需要一個計劃驅(qū)動的開發(fā)方法，要求進行仔細的需求分析。因此，瀑布模型是最適合使用的方法，或許可以在不同開發(fā)階段之間進行正式轉(zhuǎn)換。2.虛擬現(xiàn)實系統(tǒng)：這是一個需求會變化并且具有大量用戶界面組件的系統(tǒng)。增量開發(fā)可能是最合適的模型，或許需要一些UI原型開發(fā)。可以使用敏捷過程。3.大學會計系統(tǒng)：這是一個需求相對明確的系統(tǒng)，并且將在與許多其他系統(tǒng)（如研究經(jīng)費管理系統(tǒng)）配合使用的環(huán)境中使用。因此，基于重用的方法可能是適合的。4.交互式旅行規(guī)劃系統(tǒng)：這是一個具有復雜用戶界面的系統(tǒng)，但必須穩(wěn)定可靠。由于系統(tǒng)需求會隨著用戶實際使用經(jīng)驗的積累而變化，因此增量開發(fā)方法是最合適的。2.3考慮圖2-3中所示的集成和配置過程模型。為什么在這個過程中要重復需求工程活動?您需要重復需求工程活動，因為根據(jù)系統(tǒng)/組件的可重用性來調(diào)整系統(tǒng)需求是至關重要的。這些活動包括：1.初始活動：了解系統(tǒng)功能并概述系統(tǒng)應執(zhí)行的廣泛需求。應以足夠詳細的方式表達這些需求，以便您可以據(jù)此決定某個系統(tǒng)/組件是否滿足某些需求并能夠重用。2.詳細需求工程活動：一旦選定了系統(tǒng)/組件，您需要進行更詳細的需求工程活動，以檢查重用軟件的功能是否滿足業(yè)務需求，并識別所需的更改和添加。2.4為什么在需求工程過程中區(qū)分用戶需求開發(fā)和系統(tǒng)需求開發(fā)是重要的?用戶需求和系統(tǒng)需求之間存在根本差異，這意味著應該分別考慮它們。用戶需求旨在從用戶角度描述系統(tǒng)的功能和特性，用戶理解這些需求至關重要。它們應該用自然語言表達，可能不會表達得非常詳細，以允許一些實現(xiàn)的靈活性。參與該過程的人員必須能夠理解用戶的環(huán)境和應用領域。系統(tǒng)需求比用戶需求詳細得多，旨在成為系統(tǒng)的精確規(guī)范，可能是系統(tǒng)合同的一部分。它們也可能用于開發(fā)外包的情況，開發(fā)團隊需要完整的規(guī)范說明應該開發(fā)什么。系統(tǒng)需求是在用戶需求確定后制定的。2.6為什么在復雜系統(tǒng)中變化是不可避免的?舉出一些有助于預測可能的變化并使所開發(fā)的軟件更適應變化的軟件過程活動的例子(除了原型和增量交付之外)。系統(tǒng)必須變化，因為當它們安裝在環(huán)境中時，環(huán)境會適應它們，這種適應自然會產(chǎn)生新的/不同的系統(tǒng)需求。此外，系統(tǒng)的環(huán)境是動態(tài)的，隨著業(yè)務、業(yè)務目標和業(yè)務政策的變化不斷產(chǎn)生新需求。除非系統(tǒng)適應這些需求，否則其功能將與支持業(yè)務所需的功能脫節(jié)，從而變得不那么有用。支持變化的過程活動示例包括：記錄需求的理由：記錄需求被包含的原因，這有助于未來的變化。需求可追溯性：顯示需求之間以及需求與系統(tǒng)設計/代碼之間的依賴關系。設計建模：設計模型記錄軟件的結(jié)構。代碼重構：通過提高代碼質(zhì)量，使其更易于變更。2.9指出SEI的能力成熟度框架中所包含的過程評估和改進方法的兩個優(yōu)點和兩個缺點流程改進框架的優(yōu)勢這種方法提供了一種衡量流程當前狀態(tài)的手段，以及一種引入流程改進的有序方法。它作為借鑒其他人在流程改進方面的經(jīng)驗的一種方式非常有用。流程改進框架的劣勢與任何測量系統(tǒng)一樣，存在一種傾向，即為了提升測量結(jié)果而進行改進，而不是專注于滿足實際業(yè)務目標的改進。成熟度模型方法操作起來成本高昂且官僚。它并不真正適合那些采用敏捷開發(fā)方法。第三章敏捷軟件開發(fā)3.2敏捷方法所基于的原則是如何加快軟件的開發(fā)和部署的?敏捷開發(fā)的基本原則是：個人和交互勝過過程和工具。通過利用個人技能和能力，并確保開發(fā)團隊了解彼此的工作，避免了正式溝通和過程保證的開銷。這意味著團隊可以專注于工作軟件的開發(fā)。工作軟件勝過全面的文檔。這有助于加速開發(fā)，因為不會花費時間開發(fā)、檢查和管理文檔。相反，程序員的時間集中在代碼的開發(fā)和測試上?？蛻魠f(xié)作勝過合同談判。敏捷開發(fā)人員認為，與其花費時間開發(fā)、分析和談判要包含在系統(tǒng)合同中的需求，不如在開發(fā)過程中直接從客戶那里獲得關于需求的反饋更有效。這允許比需要合同的情況更早地開發(fā)和交付有用的功能。響應變化勝過遵循計劃。敏捷開發(fā)人員正確地認為，對變化做出響應比遵循基于計劃的過程更有效，因為無論使用什么過程，變化都是不可避免的。更改計劃以適應變化會產(chǎn)生巨大的開銷，而計劃的不靈活性意味著可能會做一些后來被丟棄的工作。3.3極限編程將用戶需求表達為故事，每個故事寫在卡片上。討論這種方法對于需求描述的優(yōu)點和缺點故事的優(yōu)點：它們代表了經(jīng)常出現(xiàn)的真實情況，因此系統(tǒng)將支持最常見的用戶操作。用戶很容易理解和評論故事。它們代表了功能的增量——實現(xiàn)一個故事為用戶提供了一些價值。故事的缺點：它們可能不完整，而且它們的非正式性質(zhì)使得這種不完整性難以察覺。它們關注的是功能需求，而不是非功能需求。當使用故事時，不可能表示性能和可靠性等橫切系統(tǒng)需求。系統(tǒng)架構和用戶故事之間的關系不清楚，因此架構設計很困難。3.6比較Scrum方法和傳統(tǒng)的基于計劃的方法中的項目管理(如第23章所介紹的)。你的比較應該基于每種方法對項目人員分配計劃、項目成本估算、維持團隊延續(xù)性、管理項目團隊成員變化等方面的有效性1.項目人員分配計劃ScrumScrum采用非正式的方式進行人員分配。團隊成員會根據(jù)產(chǎn)品待辦事項列表中的功能特性，如果認為自己的專長合適，就會“競標”來實施這些功能。或者，Scrum主管也可以分配任務。在Scrum中，沒有正式的機制來規(guī)劃具備非常特殊專長的項目成員臨時分配到一個團隊中。這種需求必須由Scrum主管識別，并且他或她需要討論如何提供這些專長?；谟媱澋拈_發(fā)項目計劃用于識別系統(tǒng)要交付的部分，并在需求文檔中加以說明。然后可以識別出每個部分所需的專長，并基于此規(guī)劃人員分配到項目中。2.項目成本估算Scrum項目成本是基于軟件的預期交付日期和Scrum團隊中的人員來估算的。系統(tǒng)的功能會進行調(diào)整，以確保在原始成本估算內(nèi)總能交付一些可工作的系統(tǒng)。當然，這可能對客戶來說不夠充分，他們需要參與重新安排系統(tǒng)交付的時間。基于計劃的開發(fā)項目成本基于需求文檔中指定的功能性以及系統(tǒng)的非功能性需求進行分析。成本可能會根據(jù)團隊規(guī)模和交付時間進行調(diào)整。通常情況下，成本會被低估，最終項目的實際成本會遠高于最初的估算。團隊成員的平均成本是默認的。3.維持團隊凝聚力Scrum團隊成員每天會面，無論是面對面還是通過電子方式。鼓勵廣泛的非正式討論和溝通。團隊成員從項目待辦事項中協(xié)商工作任務。這一切都促成了產(chǎn)品所有權的共同感和一個非常有凝聚力的團隊。基于計劃的開發(fā)團隊凝聚力是項目經(jīng)理的責任，他或她必須采取明確的行動來促進這一點?？傮w方法依賴于相對不頻繁的正式會議，這并不利于發(fā)展一個有凝聚力的團隊。4.管理項目團隊成員的變動Scrum這是Scrum中很少討論的話題，但卻是一個根本性問題，因為很多信息是非正式的，依賴于人們記住已經(jīng)達成的共識。當有人離開時，尤其是在很少有項目文檔的情況下，很難讓新成員快速上手。基于計劃的開發(fā)項目管理計劃圍繞專長而不是個人制定，并且項目文檔應該是可用的。因此，如果團隊成員離開，那么具有相當專長的新成員可以閱讀已完成的工作，在理解之后，應該能夠作為替代者。3.8為什么在將敏捷方法規(guī)?；瘧玫接煞植际介_發(fā)團隊開發(fā)的更大項目中的時候，有必要從基于計劃的方法中引入一些方法和文檔?當大型團隊開發(fā)軟件時，項目規(guī)劃通常至關重要。這包括確保在開發(fā)過程中需要時，可以獲取合適的人員，以及確保由不同團隊開發(fā)的系統(tǒng)不同部分能夠協(xié)調(diào)交付。這意味著如果部分A依賴于部分B，時間表應確保在部分A開發(fā)之前先完成部分B。需求分析和文檔化對于決定如何分配工作并確保每個團隊對其他團隊的工作有一定的了解非常重要。設計文檔，尤其是接口規(guī)范，對于團隊能夠獨立開發(fā)而不需要接觸正在開發(fā)中的軟件非常重要。風險管理可能需要確保所有團隊了解面臨的風險，并能夠組織工作以最小化這些風險。風險管理也可能有助于應對不同團隊采用的不同交付時間表3.10讓一個用戶緊密參與軟件開發(fā)團隊的一個問題是他們會被“同化”。也就是說，他們會采用開發(fā)團隊的觀點，并丟掉關于用戶需要的觀點。提出3種有利于避免這一問題的方法，并討論每種方法的優(yōu)點和缺點讓多個用戶參與到開發(fā)團隊中。優(yōu)點是您可以獲得關于問題的多個視角，更好地覆蓋用戶任務，從而獲得需求，并且不太可能有非典型用戶。缺點是成本、讓用戶參與的困難以及可能的用戶沖突。改變參與團隊的用戶。優(yōu)點同樣是多個視角。缺點是每個用戶都需要時間才能發(fā)揮生產(chǎn)力，以及可能來自不同用戶的相互沖突的需求。與其他用戶代表驗證用戶建議。優(yōu)點是對建議進行獨立檢查；缺點是這會減慢開發(fā)過程，因為進行檢查需要時間。第四章需求工程4.2找出下面這段售票系統(tǒng)需求陳述中有二義或遺漏的地方：一個自動化的售票機銷售火車票。用戶選擇他們的目的地并輸入信用卡和個人身份信息。機器吐出火車票，而用戶的信用卡賬戶會進行付款。當用戶按下啟動按鈕，一個顯示候選目的地的菜單被激活，同時系統(tǒng)向用戶顯示一條選擇目的地以及所需要的票的類型的消息。一旦選擇了目的地，系統(tǒng)顯示票價并請客戶輸入他們的信用卡。檢查信用卡是否有效之后，系統(tǒng)請用戶輸入個人身份(PIN碼)。信用卡交易確認后，票被吐出。存在的歧義和遺漏包括：客戶是否可以一次性購買多個同一目的地的車票，還是必須逐個購買？如有誤操作，客戶能否取消購票請求？若輸入無效卡，系統(tǒng)應如何處理？若客戶在選擇目的地前就插入卡（類似于ATM機操作），會出現(xiàn)什么情況？若客戶想購買去往其他目的地的車票，是否需要再次按下“開始”按鈕？系統(tǒng)是否僅提供從機器所在車站出發(fā)的直接連接車站的車票，還是包括所有可能的目的地？4.4為售票系統(tǒng)書寫一組非功能性需求，明確所期望的可靠性和響應時間。售票系統(tǒng)的可能非功能需求包括：在任何一天的06:00到23:00之間，整個系統(tǒng)的停機時間不應超過5分鐘。在任何一天的06:00到23:00之間，系統(tǒng)故障后的恢復時間不應超過2分鐘。在任何一天的23:00到06:00之間，整個系統(tǒng)的停機時間不應超過20分鐘。所有這些都是可用性要求——請注意，這些要求根據(jù)一天中的時間而有所不同。在大多數(shù)人旅行時發(fā)生的故障比在客戶很少時發(fā)生的故障更不可接受。在客戶按下機器上的按鈕后，顯示器應在0.5秒內(nèi)更新。在收到信用卡驗證后，出票時間不應超過10秒。在驗證信用卡時，顯示屏應為客戶提供狀態(tài)消息，表明正在進行活動。這告訴客戶驗證這種可能耗時的活動仍在進行中，而且系統(tǒng)并沒有簡單地失敗。售票請求的最大可接受故障率為1:10000。請注意，這實際上是ROCOF。我沒有指定可接受的錯誤票數(shù)量，因為這取決于系統(tǒng)是否包括允許記錄客戶請求的跟蹤設施。如果是這樣，相對較高的故障率是可以接受的，因為客戶可以投訴并獲得退款。如果沒有，只有非常低的故障率是可以接受的。顯然，這些要求是任意的，還有許多其他可能的答案。您只需檢查它們的可信度。4.6一個負責起草系統(tǒng)需求規(guī)格說明的工程師，應當如何記錄功能性需求和非功能性需求之間的關系?請給出你的建議追蹤功能需求和非功能需求之間的關系是復雜的，因為非功能需求往往是針對整個系統(tǒng)的，而不是單一功能或一組功能。一種可行的方法是明確指出與特定功能需求相關的系統(tǒng)級非功能需求，并將它們單獨羅列。所有對每個功能需求有影響的系統(tǒng)需求都應被詳細列出?？梢酝ㄟ^如下表所示的方式，將它們聯(lián)系起來。功能要求相關的非功能性系統(tǒng)需求非功能性需求系統(tǒng)應提供一種操作，允許操作員打開釋放閥，將蒸汽排入大氣中。安全要求：如果在蒸汽發(fā)生裝置上進行維護工作，則不得釋放蒸汽。時間要求：操作員開始行動后，閥門必須在2秒內(nèi)完全打開。在這個例子中，請注意系統(tǒng)級非功能需求通常會比針對特定操作的定時要求具有更高的優(yōu)先級。顯然，任何能夠合理地將功能需求和非功能需求聯(lián)系起來的方法都是可以接受的。4.7根據(jù)你自己關于ATM機使用的經(jīng)驗，開發(fā)一組可以作為理解ATM機系統(tǒng)需求的基礎的用況有多種不同類型的自動取款機，所以，顯然，不可能有一套確定的用例可以產(chǎn)生。然而，我期望看到涵蓋主要功能的用例，如提取現(xiàn)金、顯示余額、打印對賬單、更改密碼和存入現(xiàn)金。用例描述應該描述所涉及的參與者、輸入和輸出、正常操作和異常情況。取款：參與者：客戶，ATM，會計系統(tǒng)輸入：客戶的卡，PIN，銀行賬戶詳情輸出：客戶的卡，收據(jù)，銀行賬戶詳情正常操作：客戶將卡插入機器。他/她被提示輸入PIN，并在鍵盤上輸入。如果正確，他/她將看到一系列選項。選擇“取款”選項。客戶被提示輸入所需現(xiàn)金金額并輸入金額。如果賬戶中有足夠的資金，現(xiàn)金將被分配，打印收據(jù)并更新賬戶余額。在分配現(xiàn)金之前，卡片被退還給客戶，機器提示客戶取卡。異常：無效卡?？ㄆ粰C器保留；建議客戶尋求建議。PIN錯誤。請求客戶重新輸入PIN。如果3次嘗試后仍然錯誤，卡片被機器保留，并建議客戶尋求建議。余額不足。交易終止。卡片退還給客戶。顯示余額：參與者：客戶，ATM，會計系統(tǒng)輸入：客戶的卡，PIN，銀行賬戶詳情輸出：客戶的卡正常操作：客戶使用卡和PIN進行身份驗證，如“取款”并選擇“顯示余額”選項。他們賬戶的當前余額顯示在屏幕上?？ㄆ诉€給客戶。異常：無效卡。如“取款”所述PIN錯誤。如“取款”所述打印對賬單：參與者：客戶，ATM，會計系統(tǒng)輸入：客戶的卡，PIN，銀行賬戶詳情輸出：客戶的卡，打印的對賬單正常操作：客戶使用卡和PIN進行身份驗證，如“取款”并選擇“打印對賬單”選項。他們賬戶的最后五筆交易被打印出來。卡片退還給客戶。異常：無效卡。如“取款”所述PIN錯誤。如“取款”所述更改PIN：參與者：客戶，ATM輸入：客戶的卡，PIN輸出：客戶的卡正常操作：客戶進行身份驗證，如“取款”并選擇“更改PIN”選項。他/她被提示兩次輸入新PIN。輸入的PIN應該相同。客戶的PIN被加密并存儲在卡上。卡片退還給客戶。異常：無效卡。如“取款”所述。PIN錯誤。如“取款”所述。PIN不匹配。邀請客戶重復過程以重置他/她的PIN。存款：參與者：客戶，ATM，會計系統(tǒng)輸入：客戶的卡，PIN，銀行賬戶詳情，要存款的現(xiàn)金輸出：客戶的卡，收據(jù)正常操作：客戶使用卡和PIN進行身份驗證，如“取款”并選擇“存款”選項?？蛻舯惶崾据斎胍婵畹默F(xiàn)金金額并輸入金額。然后，他或她將獲得一個存款信封，將現(xiàn)金放入其中然后將其退還給機器。客戶的賬戶余額被更新為存款金額，但這被標記為未清算資金，直到檢查后才清算。發(fā)出收據(jù)，并退還客戶的卡。異常：無效卡。如“取款”所述。PIN錯誤。如“取款”所述。在信封發(fā)出1分鐘內(nèi)未存款。交易終止。卡片退還給客戶。4.9當系統(tǒng)面臨必須滿足的緊急修改時，系統(tǒng)中的軟件可能不得不在相應的需求變更被批準前就進行修改。建議一個實施這類修改的過程模型，使之可以確保需求文檔和系統(tǒng)實現(xiàn)不會變得不一致下圖展示了一個用于保持需求文檔與系統(tǒng)一致性的變更流程。該流程應對變更設定優(yōu)先級，確保緊急變更得到及時處理，并在修改系統(tǒng)需求時優(yōu)先考慮這些變更。變更后的代碼應作為最終變更流程的輸入。同時，當有更多時間進行分析時，可能會發(fā)現(xiàn)更優(yōu)的變更方法。分析變更請求[緊急變更]修改程序代碼記錄代碼更改重新提交變更請求以待分析變更請求數(shù)據(jù)庫[非緊急變更]評估需求影響更改需求設計/修改代碼更新變更請求數(shù)據(jù)庫第五章系統(tǒng)建模5.2如何使用一個已經(jīng)存在的系統(tǒng)模型?解釋為什么這樣一個系統(tǒng)模型并不一定是完整和正確的。如果你在開發(fā)一個新系統(tǒng)的模型情況還是這樣嗎?您可能會創(chuàng)建并使用一個已經(jīng)存在的系統(tǒng)的模型，原因包括：為了理解和記錄現(xiàn)有系統(tǒng)的架構與運作方式。作為討論對該系統(tǒng)可能變更的焦點。為了指導系統(tǒng)的重新實施。除非您的目的是完全記錄現(xiàn)有系統(tǒng)的操作，否則您不需要一個完整的模型。在這種情況下，模型的目的是幫助您處理系統(tǒng)的某些部分，因此只需要對這些部分進行建模。此外，如果模型被用作討論焦點，您可能不會對細節(jié)感興趣，因此可以在模型中忽略系統(tǒng)的部分。一般來說，對于新系統(tǒng)的模型也是如此，除非正在進行基于模型的開發(fā)，這種情況下需要一個完整的模型。您可能需要完整模型的另一種情況是，根據(jù)合同要求，必須將此類模型作為系統(tǒng)文檔的一部分產(chǎn)生。5.5開發(fā)一個順序圖來描述一所大學中的一個學生注冊一門課程時所涉及的交互。課程可能有人數(shù)限制，因此注冊過程必須包含針對是否還有空位的檢查。假設學生通過訪問一個電子課程目錄來找出可選的課程5.6仔細觀察你所使用的電子郵件系統(tǒng)中消息和郵箱是如何表示的。建模為了表示郵箱和電子郵件消息而需要在系統(tǒng)實現(xiàn)中使用的對象類Mailmessage（郵件信息）:sender（發(fā)送者）receiverlist（接收者列表）cclist（抄送列表）bcclist（密送列表）date（日期）subject（主題）returnpath（返回路徑）routinginfo（路由信息）spaminfo（垃圾信息）mailer（郵件發(fā)送者）messageinfo（消息信息）messagebody（消息主體）attachments（附件）signature（簽名）read（）reply（）replyall（）print（）forward（）send（）Mailbox（郵箱）:name（名稱）pathname（路徑名）creationdate（創(chuàng)建日期）changedate（更改日期）messages（消息）unreadmessages（未讀消息）flaggedmessages（已標記的消息）deletedmessages（已刪除的消息）movemessage（）copymessage（）deletemessage（）fetchmail（）（提取郵件）create（）rename（）delete（）5.7基于你對于銀行ATM機的經(jīng)驗，畫一個活動圖來建模當一個客戶從機器中提取現(xiàn)金時所涉及的數(shù)據(jù)處理5.10你是一個軟件工程經(jīng)理，你的團隊中的一個資深成員提出應當使用模型驅(qū)動的工程來開發(fā)一個新系統(tǒng)。你在決定是否應該將該方法引入軟件開發(fā)中時要考慮哪些因素?在做出決策時，應考慮以下幾個因素：團隊對UML和MDA的掌握程度（團隊是否已具備相關專業(yè)知識，還是需要接受大量培訓）支持MDA的工具有效性和成本（工具是否已內(nèi)部可用，或需另行購買。它們是否滿足正在開發(fā)的軟件類型的需求）軟件的預期使用壽命（MDA更適用于長期使用的系統(tǒng)）對高性能或高吞吐量的需求（MDA依賴代碼生成，可能不如手工編碼高效）采用MDA的長遠利益（這種方法是否能真正節(jié)省成本）開發(fā)團隊的熱情和承諾（團隊成員是否都支持這一新方法）在編寫規(guī)范之前可能必須設計架構，以提供一種構建規(guī)范和同時開發(fā)不同子系統(tǒng)規(guī)范的方法，以便允許分包商制造硬件，并為系統(tǒng)成本提供模型。第六章體系結(jié)構設計6.1當描述一個系統(tǒng)時，為什么必須要在得到完整的需求規(guī)格說明之前就開始系統(tǒng)體系結(jié)構的設計?在設計規(guī)范之前，可能需要先制定架構。這樣做是為了提供一個清晰的方法來結(jié)構化規(guī)范，并允許同時開發(fā)各種子系統(tǒng)規(guī)范。這樣的做法有助于分包商制造硬件，并且為系統(tǒng)成本估算提供了一個模型。6.3在為一個可用性和信息安全需求都是最重要的非功能性需求的系統(tǒng)設計體系結(jié)構時，為什么可能會出現(xiàn)設計沖突?從根本上說，為了提供可用性，架構中需要有（a）復制的組件，以便在一個組件失敗時，可以立即切換到備份組件。同時，還需要有正在處理的數(shù)據(jù)的多個副本。安全性要求最小化數(shù)據(jù)副本的數(shù)量，并在可能的情況下，采用每個組件只了解完成其工作所需的信息的架構。這減少了入侵者訪問數(shù)據(jù)的機會。因此，可用性（復制，多個副本）和安全（專業(yè)化，最小副本）之間存在根本的建筑沖突。系統(tǒng)架構師必須在這些根本對立的要求之間找到最佳的折衷方案。6.7將要開發(fā)一個信息系統(tǒng)以用于維護關于一個公用事業(yè)公司所擁有資產(chǎn)(例如建筑、車輛、設備)的信息。希望該系統(tǒng)可以在新的資產(chǎn)信息可用時，在現(xiàn)場工作的員工可以使用移動設備進行更新。該公司有幾個已有的資產(chǎn)數(shù)據(jù)庫，它們應當通過該系統(tǒng)進行集成?；趫D6-18中所示的通用信息系統(tǒng)體系結(jié)構，為這個資產(chǎn)管理系統(tǒng)設計一個分層體系結(jié)構。1.BrowserUI和MobileUI：BrowserUI：瀏覽器用戶界面MobileUI：移動設備用戶界面2.中間層（從左到右）：Mobiledevicemanagement：移動設備管理Formsmanager：表單管理器Alertmanager：警報管理器Authenticationandauthorization：認證和授權3.最下面一層（從左到右）：Databasesearch：數(shù)據(jù)庫搜索Databasealerts：數(shù)據(jù)庫警報Databasebrowser：數(shù)據(jù)庫瀏覽器Databasequerymanagement：數(shù)據(jù)庫查詢管理Buildingsdatabase：建筑物數(shù)據(jù)庫Equipmentdatabase：設備數(shù)據(jù)庫Infrastructuredatabase：基礎設施數(shù)據(jù)庫Vehicledatabase：車輛數(shù)據(jù)庫6.8使用這里所介紹的語言處理系統(tǒng)通用模型，設計一個系統(tǒng)的體系結(jié)構，該系統(tǒng)接受自然語言命令，并將其翻譯為數(shù)據(jù)庫查詢語言(例如SQL)。Dictionary:字典Abstractsyntaxtree:抽象語法樹Lexicalanalysis:詞匯分析Partofspeechtagger:詞性標注器Commandparser:命令解析器Parameteranalysis:參數(shù)分析SQLcodegenerator:SQL代碼生成器6.9使用如圖6-18中所示的信息系統(tǒng)基本模型，針對一個面向移動設備用于顯示某個特定機場航班到達和起飛信息的應用，建議其中應該包含哪些構件?這是一個混合系統(tǒng)，系統(tǒng)的某些元素托管在遠程服務器上，而某些元素則內(nèi)置在應用程序中。您需要考慮信息系統(tǒng)的各個層次，并識別可能包含在每個層次中的組件。這些組件的例子可能包括：第1層（數(shù)據(jù)庫級別）：航班數(shù)據(jù)庫；航班狀態(tài)數(shù)據(jù)庫；機場信息；第2層（信息檢索級別）：狀態(tài)管理；航班管理；搜索；第3層（用戶交互級別）：認證；會話管理；表單處理（）第4層（用戶界面）：應用程序UI然后，您需要決定哪些信息系統(tǒng)元素應該在移動設備上托管，哪些應該遠程托管。1.數(shù)據(jù)庫級別很明顯，試圖在應用程序上托管主要的數(shù)據(jù)庫組件是沒有意義的，因此在應用程序中，這些被一個數(shù)據(jù)庫查詢組件所替代，該組件提供了對這些數(shù)據(jù)庫的訪問權限。2.信息檢索級別應用程序中需要一個搜索組件，但這實際上應該是運行在服務器上的更廣泛數(shù)據(jù)庫搜索的前端。用戶感興趣的航班及其狀態(tài)信息必須在應用程序中本地收集和管理。3.用戶交互級別這也必須在應用程序中處理，盡管它基于存儲的信息，例如認證依賴于存儲用戶的憑據(jù)，并在調(diào)用應用程序時自動進行認證。4.用戶界面級別僅在應用程序中實現(xiàn)第七章設計和實現(xiàn)7.1使用圖7-3中所示的表格化表示法對氣象站用況“報告狀態(tài)和重配置”進行描述。你應當對這里所需要的功能做出合理的假設系統(tǒng)：氣象站用況：報告狀態(tài)參與者：氣象信息系統(tǒng)、氣象站數(shù)據(jù)：氣象站向氣象信息系統(tǒng)發(fā)送狀態(tài)更新，提供有關其儀器、計算機和電源供應的狀態(tài)信息。激勵：氣象信息系統(tǒng)與氣象站建立衛(wèi)星鏈接并請求狀態(tài)信息。響應：狀態(tài)摘要上傳到氣象信息系統(tǒng)備注：系統(tǒng)狀態(tài)通常與天氣報告同時被激勵。系統(tǒng)：氣象站用況：重新配置參與者：氣象信息系統(tǒng)、氣象站數(shù)據(jù)：氣象信息站向氣象站發(fā)送重新配置命令。這將其置于遠程控制模式，在該模式下，可以從遠程系統(tǒng)發(fā)送進一步的命令來更新氣象站軟件。激勵：來自氣象信息系統(tǒng)的命令。響應：確認系統(tǒng)處于遠程控制模式備注：在必須安裝軟件更新時偶爾被激勵。7.3使用UML對于對象類的表示法設計下列對象類，識別屬性和操作。根據(jù)你自己的經(jīng)驗來決定與這些對象相關聯(lián)的屬性和操作。一個移動電話或者平板電腦上的消息通信系統(tǒng)一個個人計算機的打印機一個個人音樂系統(tǒng)一個銀行賬戶一個圖書館目錄這里有許多可能的設計，并且可以給對象增加大量的復雜性。然而，我真正尋找的只是簡單對象，這些對象封裝了這些工件的主要需求?？赡艿脑O計顯示在下面的圖中。1.Messagingsystem（消息系統(tǒng)）message(status,sender,length,body)（消息（狀態(tài)、發(fā)送者、長度、主體））messagelist（消息列表）attachments（附件）create_message()（創(chuàng)建消息）send_message()（發(fā)送消息）copy_message()（復制消息）select_message()（選擇消息）edit_message()（編輯消息）add_to_list()（添加到列表）remove_from_list()（從列表中刪除）view_attachment()（查看附件）notify()（通知）2.Librarycatalogue（圖書館目錄）Publicationrecords（出版物記錄）Transactions（交易）Datecreated（創(chuàng)建日期）Dateupdated（更新日期）Permissions（權限）keywordindex（關鍵詞索引）newentry()（新條目）editentry()（編輯條目）deleteentry()（刪除條目）search()（搜索）create_index()（創(chuàng)建索引）editpermissions()（編輯權限）recordtransaction()（記錄交易）3.Musicsystem（音樂系統(tǒng)）songstore（歌曲庫）playlists（播放列表）volume（音量）nowplaying（正在播放）recentlyplayed（最近播放）display（顯示）batterylevel（電池電量）play()（播放）stop()（停止）selectplaylist()（選擇播放列表）selectsong()（選擇歌曲）search()（搜索）randomplay()（隨機播放）repeat()（重復）changevolume()（改變音量）displaystatus()（顯示狀態(tài)）4.Printer（打印機）document（文檔）tonerlevel（墨粉水平）paperstatus（紙張狀態(tài)）errorstatus（錯誤狀態(tài)）display（顯示）setup_printer()（設置打印機）print()（打?。ヽancelprintjob()（取消打印作業(yè)）selftest()（自檢）startup()（啟動）shutdown()（關閉）5.BankAccount（銀行賬戶）accountnumber（賬號）accounttype（賬戶類型）dateopened（開戶日期）dateclosed（關閉日期）balance（余額）transactionlist（交易列表）overdraftlimit（透支限額）open()（打開）close()（關閉）credit()（信貸）debit()（借記）showbalance()（顯示余額）editoverdraftlimit()（編輯透支限額）addtransaction()（添加交易）listtransactions()（列出交易）7.7畫一個順序圖展示小組日程系統(tǒng)在一組人正在安排一個會議時對象間的交互Organizer（組織者）G:GroupDiary（G組日記）D1:Diary（D1日記）D2:Diary（D2日記）D3:Diary（D3日記）Setup(window,participants)（設置（窗口，參與者））getAvail(W1,P1)（獲取可用性（W1，P1））Availdates(p1)（可用日期（p1））getAvail(W2,p2)（獲取可用性（W2，p2））Availdates(p2)（可用日期（p2））getAvail(W3,p3)（獲取可用性（W3，p3））Availdates(p3)（可用日期（p3））reserve(date)（預訂（日期））confirm(date)（確認（日期））report(window)（報告（窗口））[Datesavailable]：日期可用[Nodatesavailable]：沒有可用日期在上述圖表中，假設會議有3名參與者，包括一名組織者。組織者提出一個會議時間“范圍”，涉及相關參與者。團隊日歷會依次與每位參與者的日歷進行協(xié)調(diào)，根據(jù)他們的時間安排來調(diào)整這個范圍。例如，如果組織者提議的會議時間是6月18日至19日，團隊日歷首先查看組織者的日歷（D1），確認這些日期是否有空。然后，團隊日歷將這個確認后的時間范圍告知參與者D2的日歷，而不是最初提議的時間范圍。如果在這個時間范圍內(nèi)沒有找到大家都有空的日期，系統(tǒng)會通知組織者。如果有可行的日期，系統(tǒng)會選定一個日期，更新所有相關日歷，并通知組織者確認。7.9舉例解釋為什么一組人在開發(fā)一個軟件產(chǎn)品時配置管理系統(tǒng)很重要配置管理的目標有兩個：一是確保不同開發(fā)人員對系統(tǒng)的更改不會相互影響；二是保證能夠隨時創(chuàng)建系統(tǒng)的特定版本。如果沒有配置管理，就很難追蹤每位開發(fā)人員對代碼所做的修改，而且后一個程序員的改動可能會覆蓋前一個程序員的成果。比如，一個程序員可能修改了一個組件來提升性能，而另一個程序員可能修復了該組件的一個功能錯誤。如果沒有配置管理，最后提交代碼的開發(fā)者可能會覆蓋之前的改動，導致之前的修改丟失。此外，一個系統(tǒng)通常由多個組件組成，每個組件都有多個版本，每個版本都有其特定用途。例如，可能存在適用于Windows、Linux和MacOS等不同平臺的系統(tǒng)版本。這些版本中有些組件是特定的，有些是共享的，如果沒有配置管理工具的幫助，組裝這些版本很容易出錯。一旦在某個版本中錯誤地包含了不合適的組件，就很可能導致軟件后續(xù)出現(xiàn)故障。7.10一個小公司開發(fā)了一個可以專門為每個客戶專門配置的專業(yè)軟件產(chǎn)品。新客戶通常都有一些特定的需求要加入到系統(tǒng)中，他們會為這些需求的開發(fā)和集成支付費用。該軟件公司有一個機會去投標一個新項目，這將會使客戶基數(shù)翻倍。新客戶希望參與一些系統(tǒng)的配置。解釋為什么在這種情況下讓這個軟件產(chǎn)品開源對于擁有該軟件的公司而言可能是個好主意開源的主要好處在于它將開發(fā)開放給廣泛的開發(fā)人員，從而加速產(chǎn)品的開發(fā)和調(diào)試。如果客戶群翻倍，小公司將面臨巨大壓力，因為他們需要招募大量新員工，因此通過開源可以降低擴展成本。在這種情況下，由于產(chǎn)品專門針對不同用戶的需求，擁有該軟件的公司仍然可以向這些用戶收取對系統(tǒng)進行更改的費用。因此，銷售軟件的收入損失可以通過增加的服務更多客戶的努力來彌補。此外，大公司通常不愿意從可能倒閉的小公司購買產(chǎn)品。某種程度上，開源為客戶提供了保障，即使原始軟件所有者不可用，他們也可以獲得源代碼，從而繼續(xù)維護他們的系統(tǒng)。最后，開源可能會增加人們對公司產(chǎn)品的了解，從而吸引更多客戶。第八章軟件測試8.2為什么測試只能表明錯誤的存在，而不是顯示沒有錯誤存在?假設對一個程序進行窮舉測試，即檢查每個可能的有效輸入，是不可能的（對于所有但微不足道的程序都是如此）。測試用例要么沒有揭示程序中的錯誤，要么揭示了程序錯誤。如果它們揭示了程序錯誤，那么它們就證明了存在錯誤。然而，如果它們沒有揭示錯誤，這僅僅意味著它們已經(jīng)執(zhí)行了一個對于所選輸入來說沒有錯誤的代碼序列。對同一代碼序列的下一次測試（使用不同的輸入）可能會揭示錯誤。8.4你被安排測試“Paragraph”對象中一個名為catWhiteSpace的方法，該方法在一個段落里面將所有連續(xù)的空格符替換成單個的空格符。為這個例子確定測試劃分，并且為catWhiteSpace方法設計一組測試。測試分為以下幾個部分：只包含單個空格的字符串。字符串中間有連續(xù)空格。字符串開頭或結(jié)尾有連續(xù)空格。測試示例包括：Thequickbrownfoxjumpedoverthelazydog（單個空格）Thequickbrownfoxjumpedoverthelazydog（中間空格數(shù)量不同）“Thequickbrownfoxjumpedoverthelazydog”（開頭有空格序列）“Thequickbrownfoxjumpedoverthelazydog”（結(jié)尾有空格序列）“Thequickbrownfoxjumpedoverthelazydog”（開頭兩個空格）“Thequickbrownfoxjumpedoverthelazydog”（開頭多個空格）“Thequickbrownfoxjumpedoverthelazydog”（結(jié)尾兩個空格）“Thequickbrownfoxjumpedoverthelazydog”（結(jié)尾多個空格）8.5什么是回歸測試?解釋該如何使用自動化測試以及JUnit這樣的測試框架來簡化回歸測試回歸測試是在開發(fā)新功能或更改系統(tǒng)時，對已經(jīng)實現(xiàn)的功能運行測試的過程。回歸測試檢查系統(tǒng)更改是否沒有給先前實現(xiàn)的代碼引入問題。自動化測試和測試框架（如JUnit）極大地簡化了回歸測試，因為每次更改時都可以自動運行整個測試集。自動化測試包括它們自己的檢查，以確定測試是否成功，否則檢查回歸測試成功與否的成本很低。8.7編寫一個可以用于為野外氣象站系統(tǒng)設計測試的場景一個可能的氣象站系統(tǒng)高級測試場景是：約翰是一名氣象學家，負責為明尼蘇達州制作氣象地圖。這些地圖是使用氣象繪圖系統(tǒng)從自動收集的數(shù)據(jù)中生成的，它們顯示了明尼蘇達州天氣的不同數(shù)據(jù)。約翰選擇要生成地圖的區(qū)域、地圖的時間段，并請求生成地圖。在創(chuàng)建地圖時，約翰運行一個氣象站檢查，檢查所有遠程收集的氣象站數(shù)據(jù)，并查找數(shù)據(jù)中的間隙——這意味著遠程氣象站存在問題。這里有許多可能的替代場景。它們應該確定所涉及的參與者的角色，并討論該角色可能執(zhí)行的典型任務。8.8你是如何理解術語“壓力測試”的?談一談如何對Mentcare系統(tǒng)進行壓力測試壓力測試是指故意將系統(tǒng)的負載增加到超過其設計限制，以觀察它如何應對高負載。系統(tǒng)應該優(yōu)雅地降級，而不是崩潰Mentcare系統(tǒng)被設計為客戶端-服務器系統(tǒng)，具有下載到客戶端的可能性。要對系統(tǒng)進行壓力測試，需要安排(a)許多不同的診所同時嘗試訪問系統(tǒng)，以及(b)向系統(tǒng)中添加大量記錄。這可能涉及使用模擬系統(tǒng)來模擬多個用戶第九章軟件演化9.1為什么在現(xiàn)實環(huán)境中使用的軟件系統(tǒng)必須進行變更，否則就會逐漸失去其作用?系統(tǒng)必須改變或逐漸變得不那么有用，原因有以下幾點：系統(tǒng)的存在改變了其環(huán)境中的工作方式，這產(chǎn)生了新的需求。如果這些需求得不到滿足，系統(tǒng)的有用性就會下降。使用該系統(tǒng)的業(yè)務會根據(jù)市場力量的變化而變化，這也會產(chǎn)生新的系統(tǒng)需求。系統(tǒng)的外部法律和政治環(huán)境發(fā)生變化，產(chǎn)生了新的需求。出現(xiàn)了提供顯著好處的新技術，系統(tǒng)必須改變以利用這些技術。9.4什么情況下一個組織會決定廢棄一個被評估為高質(zhì)量和商業(yè)價值的系統(tǒng)?軟件可能被廢棄和重寫的情況示例包括：當維護成本高且組織決定投資新硬件時。無論如何，這都將涉及大量的轉(zhuǎn)換成本，因此可能會借機重寫軟件。當業(yè)務流程發(fā)生變化并且需要新的軟件來支持該流程時。當用于開發(fā)軟件的工具和語言的支持不可用時。這在早期的4GL中是一個特別的問題，在許多情況下，供應商已經(jīng)不再營業(yè)。根據(jù)當?shù)厍闆r，還有其他原因可能導致軟件被廢棄。9.5對遺留系統(tǒng)演化的策略選擇是什么?什么時候你通常會替換整個或部分系統(tǒng)而不是繼續(xù)進行軟件維護?遺留系統(tǒng)演進的戰(zhàn)略選擇是：放棄對系統(tǒng)的維護，并用新系統(tǒng)替換它。繼續(xù)維護系統(tǒng)。進行一些再工程（系統(tǒng)改進），使系統(tǒng)更易于維護并繼續(xù)維護。將系統(tǒng)的現(xiàn)有功能封裝在包裝器中，并通過編寫調(diào)用現(xiàn)有系統(tǒng)作為組件的新代碼來添加新功能。將系統(tǒng)分解為獨立的單元，并將它們包裝為組件。這與上述解決方案類似，但在系統(tǒng)的使用方式上提供了更大的靈活性。通常，在以下情況下會選擇替換選項：系統(tǒng)的硬件平臺正在被替換，公司希望標準化一些與當前系統(tǒng)不一致的開發(fā)方法，某些主要子系統(tǒng)正在被替換（例如數(shù)據(jù)庫系統(tǒng)），或者現(xiàn)有系統(tǒng)的技術質(zhì)量較低，并且目前沒有用于再工程的工具。9.7你是公司的一名軟件項目經(jīng)理，專門從事離岸石油業(yè)的軟件開發(fā)，你現(xiàn)在需要發(fā)現(xiàn)影響公司軟件系統(tǒng)的維護性的因素。你該如何設置一個程序去分析維護的過程以及提出并度量軟件的維護指標?這是一個非常開放的問題，有許多可能的答案?；旧?，學生應該確定影響可維護性的因素，例如（程序和數(shù)據(jù)的復雜性、有意義的標識符的使用、編程語言、程序文檔等）。然后，他們應該建議如何在維護成本已知的現(xiàn)有系統(tǒng)中評估這些因素，并討論交互問題。方法應該是發(fā)現(xiàn)那些維護成本特別高的程序單元，并評估這些組件和其他組件的成本因素。然后檢查相關性。其他因素可能導致異常，因此應該在問題組件中尋找這些因素。9.8簡要描述3種不同類型的軟件維護。為什么有時候很難區(qū)分它們?軟件維護的三種主要類型是：糾錯維護或故障修復。對系統(tǒng)進行的更改是為了修復報告的故障，這些故障可能是程序錯誤或規(guī)格錯誤或遺漏。適應性維護或環(huán)境適應。更改軟件以使其適應環(huán)境的變化，例如其他軟件系統(tǒng)的變化。完善性維護或功能添加。這涉及向系統(tǒng)添加新的功能或特性。有時它們很難區(qū)分，因為同一組更改可能涵蓋所有三種類型的維護。例如，系統(tǒng)中報告的故障可能通過升級其他一些軟件來修復，然后使系統(tǒng)適應使用這個新版本（糾錯+適應）。新軟件可能具有額外的功能，并且作為適應性維護的一部分，可能會添加新的特性以利用這一點。第二十二章項目管理22.2解釋最好的程序設計者為什么不一定能成為最好的軟件管理者。22.1節(jié)中列出的管理活動可以幫助你回答這個問題管理活動，如提案撰寫、項目規(guī)劃和人員選擇，需要一套技能，包括展示和溝通技能、組織技能以及與其他項目團隊成員溝通的能力。編程技能與這些技能不同（事實上，程序員經(jīng)常被批評缺乏人際交往技能），所以不能說優(yōu)秀的程序員可以重新調(diào)整他們的能力成為優(yōu)秀的管理者。22.4除了圖22-1中所列的風險，識別可能在軟件項目中出現(xiàn)的其他6種風險其他可能的風險是：技術：在達到預期交易限制之前，通信網(wǎng)絡飽和。人員：可用人員的技能水平低于預期。組織：組織變革意味著項目進度加快。工具：軟件工具無法處理大型系統(tǒng)可用的數(shù)據(jù)量。需求：引入了新的非功能性需求，需要對系統(tǒng)架構進行更改。估計：軟件的難度被低估了。22.6價格鎖定的合同，即承包人以某個確定價格投標一系統(tǒng)開發(fā)，是一種將項目風險從委托人轉(zhuǎn)移給承包人的做法。如果出現(xiàn)問題，需要由承包人承擔。分析一下為什么這種合同容易增加產(chǎn)品風險的可能性固定價格合同增加了產(chǎn)品風險的可能性，因為它們從開發(fā)過程中移除了選項。因為合同是固定價格的，承包商自然不愿意增加項目的努力或時間支出，因為這會減少他們在工作中的利潤。因此，如果出現(xiàn)問題，他們會尋找方法來減少產(chǎn)品的范圍或降低產(chǎn)品開發(fā)的成本（例如，通過減少用于測試的努力）。這兩個因素都可能導致產(chǎn)品不符合客戶的預期22.8在極限編程團隊中許多管理決策權被下放到團隊成員手中，這會帶來哪些問題?雖然將管理決策下放到團隊的概念在激勵方面很有吸引力，但可能會出現(xiàn)兩種類型的問題：決策可能主要受技術考慮因素的影響，而不是業(yè)務決策