【正文】 用增量范式可能會(huì)提供基本的文件管理 ， 編輯和文件制作功能在第一增量，更復(fù)雜的編輯和文件制作能力在第二增量 ； 拼寫(xiě)和語(yǔ)法檢查在第三增量 ， 先進(jìn)的頁(yè)面布局能力在第四增量 。 任何增量的處理流程 可 以 納入原型范式 。 增量發(fā)展是特別有用當(dāng)人員無(wú)法 在 經(jīng)營(yíng)期限為一個(gè)已成立 的 項(xiàng)目 做完美的 實(shí)施 。 當(dāng)沿著 螺旋過(guò)程流發(fā)展的時(shí)候，你對(duì)正在開(kāi)發(fā)或者維護(hù)的軟件的看法是什么？ 答： 隨著工作的螺旋向外移動(dòng) ， 產(chǎn)品走向一個(gè)更完整的狀態(tài) ，執(zhí) 行工作的抽象層次 減少了。 可以合用幾種過(guò)程模型嗎？如果可以，舉例說(shuō)明。 答： 過(guò)程模型可以合 用， 每個(gè)模型 都有 個(gè)有點(diǎn)不同的處理流程，但都執(zhí)行相同的通用框架活動(dòng)集 ： 溝通，規(guī)劃，建模，施工和交付 /反饋 。 例如線性順序模型可以作為一個(gè)有用的過(guò)程模型，在被固定的情況下，要求工作以線性的方式繼續(xù)進(jìn)行，直至完成 。 在 這 情況下，開(kāi)發(fā)者可能無(wú)法確定一種算法的效率，一個(gè)操作系統(tǒng)的適應(yīng)性或應(yīng)采取 的 人機(jī)交互的 形式 。 在這之中，以及許多其他場(chǎng)合原型模型可以提供最好的辦法 。 在其他情況下，以漸進(jìn)的方式可能是有意義的和螺旋模型的流動(dòng)可能是有效率 ， 特殊過(guò)程模型具有許多的一個(gè)或多個(gè)傳統(tǒng)的特性 。 協(xié)同過(guò)程模型定義了一套“狀態(tài)”，用你自己的話(huà)描述一下這些狀態(tài)表示什么，并指出他們?cè)趨f(xié)同過(guò)程模型中的作用。 答： 簡(jiǎn)而言之 ， 并發(fā)進(jìn)程模型假定不同的部分項(xiàng)目會(huì)有所不同階段的完整性 ， 因此，不同的軟件工程活動(dòng)都被同時(shí)執(zhí)行 。 目前的挑戰(zhàn)是管理的并發(fā)，并能夠評(píng)估該項(xiàng)目的狀態(tài) 。 開(kāi)發(fā)質(zhì)量“足夠好”的軟件，其優(yōu)點(diǎn)和缺點(diǎn)是什么？也就是說(shuō) ，當(dāng)我們追求開(kāi)發(fā)速度勝過(guò)產(chǎn)品質(zhì)量的時(shí)候，會(huì)產(chǎn)生什么后果？ 答：開(kāi)發(fā)質(zhì)量“足夠好”的軟件可能會(huì)碰到死亡線（截止時(shí)間），但質(zhì)量會(huì)是比較好的。 當(dāng)追求開(kāi)發(fā) 速度超過(guò)了產(chǎn)品的質(zhì)量，這可能會(huì)導(dǎo)致許多缺陷 ， 該軟件可能需要更多的測(cè)試 ， 設(shè)計(jì)和實(shí)施工作 。需 求定 以的不是很清楚 ，可能需要不斷地改變 。 半 調(diào)子 和速度 過(guò)快開(kāi)發(fā) 都可能導(dǎo)致無(wú)法檢測(cè)到重大 的 項(xiàng)目風(fēng)險(xiǎn) 。 質(zhì)量太 差 可能導(dǎo)致 過(guò)多的 質(zhì)量問(wèn)題和 頻繁 的返工 。 詳細(xì)描述三個(gè)適于采用基于構(gòu)件模型的軟件項(xiàng)目。 答： 我會(huì)建議推遲這個(gè)問(wèn)題直到 “ 軟件過(guò)程改進(jìn) ”這一 章 。 我們可以證明一個(gè) 軟件構(gòu)件甚至整個(gè)程序的正確性，可是為什么并不是每個(gè)人都這樣做？ 答： 這是可能的用數(shù)學(xué)技術(shù)來(lái)證明軟件組件，甚至整個(gè)程序的正確性 。 然而，對(duì)于復(fù)雜的程序，這是一個(gè)非常耗時(shí)的過(guò)程 。 用詳盡的測(cè)試是不可能證明任何不平凡的程序的正確性， 統(tǒng)一過(guò)程和 UML 是同一概念嗎？解釋你的答案。 答： UML 提供了必要的技術(shù)支持 和 面向?qū)ο蟮能浖こ虒?shí)踐 。 但它并不提供流程框架 來(lái) 指導(dǎo)項(xiàng)目團(tuán)隊(duì)，在他們的技術(shù)應(yīng)用 中。 在 近 幾年中，雅各布森， Rumbaugh 和 Booch 制定的統(tǒng)一過(guò)程中框架使用 UML 的面向?qū)ο蟮能浖こ?。 今天，統(tǒng)一的流程 和 UML 被廣泛應(yīng)用于各種 面向?qū)ο蟮捻?xiàng)目。 第四章 需求不斷的改變，理解需求問(wèn)題是軟件工程師面臨的最困難的工作之一，因此他們更少注意需求。在某些情況下，工程師們會(huì)化繁為簡(jiǎn)。其他情況下，工程師們必須嚴(yán)格地執(zhí)行具體定義的需求。需求分析是設(shè)計(jì)和施工的橋梁 ,不能跳過(guò)。 你可以嘗試使用方法比如 QFD（質(zhì)量功能部署）通過(guò)客戶(hù)訪談和觀察、調(diào)查以及檢查歷史數(shù)據(jù)（如問(wèn)題報(bào)告）為需求收集活動(dòng)獲取原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯成需求表 —— 稱(chēng)為客戶(hù)意見(jiàn)表，并由客戶(hù)和利益相關(guān)者評(píng)審。接下來(lái)使用各種圖表、矩陣和評(píng)估方法抽取 期望的需求并盡可能導(dǎo)出令人興奮的需求。 事實(shí)上 ,客戶(hù)和開(kāi)發(fā)人員會(huì)有一個(gè)協(xié)商的過(guò)程，開(kāi)發(fā)人員會(huì)要求客戶(hù)權(quán)衡產(chǎn)品的性能與產(chǎn)品成本、上市時(shí)間之間的關(guān)系。這個(gè)協(xié)商的目的是開(kāi)發(fā)一個(gè)項(xiàng)目計(jì)劃，這個(gè)計(jì)劃在滿(mǎn)足客戶(hù)需求的同時(shí)又能準(zhǔn)確反映了軟件開(kāi)發(fā)過(guò)程中約束 (如時(shí)間、人員、預(yù)算 )。不幸的是 ,這樣的項(xiàng)目計(jì)劃很難達(dá)成 ,每個(gè)客戶(hù)都有自己的觀點(diǎn)。這些觀點(diǎn)并不對(duì)其他客戶(hù)都適用，此外時(shí)間是另一個(gè)重要的約束 ,客戶(hù)可能沒(méi)有時(shí)間與開(kāi)發(fā)人員討論需求，這使得問(wèn)題更加復(fù)雜。 需求模型的目的在于描述所需的信息、功能和計(jì)算機(jī)系統(tǒng)的工作領(lǐng) 域。隨著軟件工程師對(duì)系統(tǒng)了解的深入以及利益相關(guān)者越來(lái)越了解他們真正的需求，這種需求模型是不斷變化的。因此，分析模型在任何時(shí)候都是用戶(hù)需求的簡(jiǎn)介 最好的協(xié)商是爭(zhēng)取“雙贏” ,這會(huì)使你成為是一位談判大師。這些初期步驟的成功實(shí)施可以達(dá)到一個(gè)雙贏的結(jié)果，這是繼續(xù)開(kāi)展后續(xù)的軟件工程活動(dòng)的關(guān)鍵。 第一組上下文無(wú)關(guān)問(wèn)題集主要 關(guān)注的是 客戶(hù)、總體目標(biāo)和利益。例如，需求工程師可能會(huì)問(wèn)： 誰(shuí)是這項(xiàng)工作的最初請(qǐng)求者？ 誰(shuí)將使用該解決方案？ 成功的解決方案將帶來(lái)什么樣的經(jīng)濟(jì)收益？ 對(duì)于這個(gè)解決方案你還需要其他資源嗎？ 答案略。 用例圖描述了參與者所能 觀察到 模型圖 。 用例圖 鼓勵(lì) 系統(tǒng) 的功能 視圖應(yīng)該 轉(zhuǎn)換為面向?qū)ο?的 視圖。 在 許多情況下， 為了 提供更多的相互作用， 用例圖 需要做更詳細(xì)的闡述。 任何有一些軟件項(xiàng)目需求工程經(jīng)驗(yàn)的人都開(kāi)始注意到，在特定的應(yīng)用領(lǐng)域內(nèi)某些事情在所有的項(xiàng)目中重復(fù)發(fā)生。這些分析模式在特定應(yīng)用領(lǐng)域內(nèi)提供了一些解決方案（如類(lèi)、功能、行為），在為許多應(yīng)用項(xiàng)目建模時(shí)可以重復(fù)使用。 最好的協(xié)商是爭(zhēng)取“雙贏”的結(jié)果，即利益相關(guān)者的“贏”在于獲得滿(mǎn)足客戶(hù)大多數(shù)需要的系統(tǒng)或產(chǎn)品，而作為軟 件團(tuán)隊(duì)一員的“贏”在于按照實(shí)際情況、在可實(shí)現(xiàn)的預(yù)算和時(shí)間期限內(nèi)完成工作。 當(dāng)需求確認(rèn)解釋了一個(gè)錯(cuò)誤時(shí)，每個(gè)需求有一個(gè)問(wèn)題清單。之后會(huì)有評(píng)審小組尋找它。確認(rèn)需求的評(píng)審小組包括軟件工程師、客戶(hù)、用戶(hù)、和其他利益相關(guān)者，他們?cè)跈z查系統(tǒng)規(guī)格說(shuō)明，查找內(nèi)容或解釋上的錯(cuò)誤，以及可能需要進(jìn)一步解釋澄清的地方、丟失的信息、不一致性（這是建造大型產(chǎn)品或系統(tǒng)時(shí)遇到的主要問(wèn)題）、沖突的需求或是不可實(shí)現(xiàn)的（不能達(dá)到的）需求。 第五章 有沒(méi)有可能在分析建模創(chuàng)建后立即開(kāi)始編碼？解釋你的答案，然后說(shuō)服反方。 答：分析模 型作為領(lǐng)域 對(duì)象的 設(shè)計(jì) 和結(jié)構(gòu) 的 基礎(chǔ)服務(wù)。 在定義了 對(duì)象和屬性 后 ， 就可以開(kāi)始進(jìn)行編碼， 也 就知道了 對(duì)象 之間 的 關(guān)系。 一個(gè)單憑經(jīng)驗(yàn)的分析原則是：模型“應(yīng)該關(guān)注在問(wèn)題域或業(yè)務(wù)域中可見(jiàn)的需求”。在這些域中哪些類(lèi)型的需求是不可見(jiàn)的？提供一些例子。 答：正如我們 所知道的， 在 開(kāi)始階段 很可能沒(méi)有完整 的需求規(guī)范 。 客戶(hù) 可能 不是非常 精確地確 定 他們 的 所有需求。 開(kāi)發(fā)者 也 沒(méi)有把握使用 一個(gè)具體的方法 來(lái) 正常的完成系統(tǒng)的功能和性能。 為了 需求分析和建模，不 傾向使用 迭代的方法。 分析師所將 認(rèn)識(shí)到的東西進(jìn)行建模， 并使用 此 模型作為 軟件增量 的設(shè)計(jì)的 基礎(chǔ)。 軟件增量作為流程 迭代 的 一部分 被制作 出來(lái) 。在 這些領(lǐng)域中， 需求 的類(lèi)型 是 不可見(jiàn)的 ， 可能因?yàn)?一些 功能必須在系統(tǒng) 中 實(shí)現(xiàn) ， 系統(tǒng) 展示 的行為是 什么， 屬性 定義的接口有哪些，應(yīng)用的約束有哪些？ 域分析的目的是什么？如何將域分析與需求模式概念相聯(lián)系？ 答：域分析是 持續(xù)的軟件工程活動(dòng)， 不與 任何的軟件項(xiàng)目 相 關(guān)聯(lián)。 它與 需求模式的概念 相聯(lián)系。域分析是通過(guò)一系列 活動(dòng) 進(jìn)行 表征 的過(guò)程 。 這些活動(dòng)從 識(shí)別 域開(kāi)始， 以 描述 域 中對(duì)象和類(lèi) 的規(guī)范 為結(jié)束。 有沒(méi)有可能不完成如圖 63 所示的 4 種元素就開(kāi)發(fā)出一個(gè)有效的分析模型？解釋一下。 答：如果 沒(méi)有圖 所示 的 4 大 元素， 是 不可能 開(kāi)發(fā)出 一個(gè)有效的分析模型 。分析模型作為域?qū)ο?的 設(shè)計(jì) 和 建造的 基礎(chǔ)。 構(gòu)建如下系統(tǒng)中的一個(gè)： a 你所在大學(xué)基于網(wǎng)絡(luò)的課程注冊(cè)系統(tǒng)。 b 一個(gè)計(jì)算機(jī)商店的基于 Web 的訂單處理系統(tǒng)。 c 一個(gè)小企業(yè)的簡(jiǎn)單發(fā)票系統(tǒng)。 d 內(nèi)置于電磁灶或微波爐的互聯(lián)網(wǎng)食譜。 選擇你感興趣的系統(tǒng)開(kāi)發(fā)一套試題關(guān)系圖并說(shuō)明數(shù)據(jù)對(duì)象、關(guān)系和屬性。 答：需要強(qiáng)調(diào)的是 ， 所有 的 數(shù)據(jù) 對(duì)象和 關(guān)系 一定 客戶(hù) 可見(jiàn)的。 為了 確認(rèn) 屬性正確地 反映出系統(tǒng)的需求， 屬性 應(yīng)該 被檢查 。 （無(wú)固定答案） 答案略。 什么是分析包？如何使用分析包？ 答：將分析 模型的各種元素 以包組 的方式 進(jìn)行 分類(lèi) ， 成為分析包 。為了 說(shuō)明 分析包 的作用 ，請(qǐng) 思考一下視頻游戲。 作為 視頻游戲的分析模型 ，道出了 大量的類(lèi)。 第六章 對(duì)于需求分析，結(jié)構(gòu)分析與面向?qū)ο蟛呗杂泻伪举|(zhì)區(qū)別？ 答：結(jié)構(gòu)分析，考慮把數(shù)據(jù)作為分離實(shí)體的變形的數(shù)據(jù)和過(guò)程。數(shù)據(jù)目標(biāo)是被使用它們已被定義的屬性和關(guān)系建模的。過(guò)程操作數(shù)據(jù)目標(biāo)是被使用它們?cè)谙到y(tǒng)中的數(shù)據(jù)流向建模的。 面向?qū)ο蠓治?，集中于類(lèi)的定義和它們合作對(duì)用戶(hù)需求所帶來(lái)的效果的方式。 在數(shù)據(jù)流圖中，一個(gè)箭 頭表示控制流還是其他？ 答： DFD 數(shù)據(jù)目標(biāo)是用有標(biāo)簽的箭頭所表示的。 什么是“信息流連續(xù)性”？當(dāng)重新定義一個(gè)數(shù)據(jù)流時(shí)，如何應(yīng)用它？ 答：數(shù)據(jù)流動(dòng)連續(xù)性意味著在同一等級(jí)中的輸入和輸出必須和它們的精確等級(jí)相同。 在生成 DFD 圖時(shí)，如何使用圖形化解析？ 答：在第一次需求整合會(huì)議中，應(yīng)用工程描述中分離所有名詞和動(dòng)詞的第一步被導(dǎo)出。再文法解析中，動(dòng)詞時(shí)處理和可以被如 DFD 中的 Bubbles 描述的。名詞是 DFD 中的外部實(shí)體（盒子），數(shù)據(jù)或控制目標(biāo)（箭頭），或數(shù)據(jù)存儲(chǔ)（雙實(shí)線）。 什么是控制 規(guī)格說(shuō)明？ 答： 控制規(guī)格（ CSPEC）以?xún)煞N不同的方式描述了系統(tǒng)的行為（在被提到的基準(zhǔn)線上），CSPEC 包括一系列行為的規(guī)格的狀態(tài)圖。它也包括程序行為表 —— 組合的行為規(guī)格。 PSPEC 和用例是同一事物嗎？如果不是，請(qǐng)解釋區(qū)別。 答：不是。過(guò)程規(guī)格被用于去描述所有現(xiàn)在最終精煉等級(jí)的流程模型過(guò)程（算法觀點(diǎn)）。一個(gè)有用的情況描述一系列行為包括演員和系統(tǒng)（更著重于用戶(hù)可見(jiàn)行為而非算法）。 表示行為建模時(shí)有兩種不同“狀態(tài)”類(lèi)型，它們是什么？ 答：被動(dòng)狀態(tài)展現(xiàn)出目標(biāo)屬性的正確情況。主動(dòng)狀態(tài)指明了目標(biāo) 在轉(zhuǎn)化或執(zhí)行過(guò)程中的正確情況。 如何從狀態(tài)圖區(qū)分順序圖？它們有何相似之處？ 答：狀態(tài)圖描述了系統(tǒng)的狀態(tài)并且展現(xiàn)了事件如何影響系統(tǒng)狀態(tài)。 順序圖指明了事件如何引起目標(biāo)的遷移。 —— 答案略。 第七章 是的，但是設(shè)計(jì)是隱式進(jìn)行的 —— 通常以隨意的方式進(jìn)行的。在設(shè)計(jì)過(guò)程中，我們研究程序的表現(xiàn)形式，而非程序本身。 軟件設(shè)計(jì)的目的是運(yùn)用一系列的原則、概念和實(shí)踐導(dǎo)致高質(zhì)量體系或產(chǎn)品的發(fā)展。設(shè)計(jì)的目標(biāo)是創(chuàng)建一個(gè)可以正確地實(shí)現(xiàn)所有客戶(hù)需求并有好的用戶(hù)體驗(yàn)的軟件模型。 通過(guò)開(kāi)展一 系列的正式技術(shù)評(píng)審來(lái)評(píng)估質(zhì)量。正式技術(shù)評(píng)審是由軟件團(tuán)隊(duì)成員召開(kāi)的會(huì)議。通常，根據(jù)將要評(píng)審的設(shè)計(jì)信息的范圍，選擇 2 人、 3 人或 4 人參與。每個(gè)人扮演一個(gè)角色：評(píng)判組長(zhǎng)策劃會(huì)議、擬定議程并主持會(huì)議；記錄員記錄筆記以保證沒(méi)有遺漏；制作人