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

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