【正文】 利用分離菜單，以便通用功能。在某些情況下，這會產(chǎn)生（命令的）排隊問題，并且在極端的情況下，會引起數(shù)據(jù)的丟失或者甚至是一個系統(tǒng)故障。最后， ITG 有可能太晚接手項目，導致沒有時間完成一個周密測試的 計劃和執(zhí)行。因此，其功能往往是依賴于這些耦合元件的操作。 優(yōu)點：錯誤不 會 ―滾 雪球 ‖——越滾越大 缺點：需要額外的處理時間和內(nèi)存（ 那 通常 只 是一個很小的代價）。一個獨立的測試組可能是這里最好的選擇，但這不是一個選擇。開發(fā)一組測試用例測試改程序。設計一組測試用例，保證利用基本路徑測試執(zhí)行所有語句。這可以作為筆試以及一些著名應用 GUI 的測試用例的素材 生成一系列用例來幫助測試用戶的文件材料是一個好辦法。這些評審有可能省去很多不必要的工作和修改（錯誤越早發(fā)現(xiàn)，維護的成本越低）。 答：答案會有不同 運用隨機測試、劃分方法、多類測試及 節(jié)和 節(jié)所描述的銀行應用的行為模型導出的測試，再生成另外生成 4 個測試。 （ 7） 你要測量產(chǎn)品，過程 和你自己 。也描述 3 種他們是不同人的情況。也描述 3 種他們是不同人的情況。你會選擇哪種團隊結構？為什么？你會選擇哪（些）種軟件過程模型？為什么？ 答： 一個封閉 范型 方法的團隊結構是一種選擇 。因為家庭娛樂市場的競爭非常激烈，完成 這項工作的壓力很大。 在一個為基因工程領域服務的公司中，你被指派為軟件項目經(jīng)理。 答： 分數(shù)分析 應用程序將獲得所有本科和研究生的學分課程 的成績和 在某一學期課程注冊 數(shù)據(jù)庫 。 項目 度量 是用來評估軟件項目的狀態(tài) 。對于項目 A 和 B，還需要做什么額外的測量，才能確定哪個團隊能夠更有效地排除錯誤？你建議采用什么度量能有助于做出判定？那些歷史數(shù)據(jù)可能有用？ 答：兩個團隊應該事先決定好要開發(fā)的軟件的大小和功能，例如， errors/FP 可以提供 一個規(guī)范化的 評估方法。估算該影印機軟件的功能點數(shù)。還要說明你對所需硬件的設想。 商業(yè)的應用 I/ O效率 交互式的應用 用戶 “ 等待時間 ” 微處理器的應用 cpu時間和內(nèi)存需要。假設采用方程（ 204）， p=8000。 答：略。 答：略 。要求使用基于對象點的應用組裝模型。針對不同的軟件應用領域，分別討論如何以 不同的方式來解釋性能。寫一個范圍陳述來描述該軟件，確定你的范圍陳述是“界定的”。再參考該表，討論為什 么 C++比 C 更好？ 答：用匯編語言實現(xiàn)一個功能點需要的行數(shù)在 91到 694之間平均 337行，這幾項在表中都是最大的， 一些行業(yè)分析師稱 ：每天無論使用任何語言的 程序員 都交出 相同數(shù)量的調(diào)試代碼 ，如果開發(fā)一個項目真用了匯編語言那將比用其它語言花費更多的時間，以上比較方法可以用到C 與 C++得比較。 注重質量，這是最重要的。 答： 一個簡單的分解 ： 頁面布局 定義頁面參數(shù) 分配文本區(qū)域 分配圖形區(qū)域 強調(diào)定義 （ 線，著色等 ） 輸入 /導入文本 輸入 /導入 編輯文本 編輯 圖形 出頁 /導出頁面 最終頁面布局 第十九章 用自己的話描述過程度量和項目度量之間的區(qū)別。 要求開發(fā)一個小型應用軟件，它的作用是分析一所大學開設的每一門課程，并輸出課程的平均成績（針對某個學期）。你會選擇哪種團隊結構？為什么？你會選擇哪些軟件過程模型？為什么？ 答： 一個開放 式范型 團隊結構可能是最好的，給定的時間壓力和熟悉的工作 （ 然而， 封閉的方法范式團隊可能也很好 ） 。 你被指派為一個小型軟件產(chǎn)品公司的項目經(jīng)理。你的工作是開發(fā)一個應用程序，該程序類似于你的團隊已經(jīng)做過的項目，只是規(guī)模更大而且更復雜。（ 3） 承包商建立 的 客戶的 規(guī)格 。 答：略。 （ 4）你要了解問題 （ 5） 你要 對 一個工作過程 不斷 的重復 。產(chǎn)生展示操作調(diào)用序列的測試用例。 ―測試 ‖應該從面向對象分析和設計開始？ 答： 在之后的開發(fā)過程中，面向對象分析和設計模型提供了大量與系統(tǒng)結構和行為相關的信息，因此，在生成代碼之前，這些模型必須經(jīng)過嚴格的審查。在這種情況下需要同時考慮輸入和輸出的等價類。 你能夠想出 節(jié)中沒有討論的其他測試目標嗎？ 答： 除了 那些 目標 之外還有 ： a) 一個成功的測試顯示功能和性能要求； b) 一個成功的測試發(fā)現(xiàn)文件錯誤； c) 一個成功的測試 發(fā)現(xiàn) 接口問題； d) 一個成功的 測試 驗證了程序結構，了解數(shù)據(jù)結構，界面設計和程序設計； e) 一個成功的測試，建立了一個進入一個測試案例數(shù)據(jù)庫，以后可以用于回歸測試。 答：略 第十五章 Myers[mye79]用以下程序作為測試能力的自我評估：某程序讀入三個整數(shù)值表示三角形的三條邊。 答： 開發(fā)商，如果客戶驗收測試計劃。 。因此， 驗證和系統(tǒng)測試 要 相結合。 列出一些可能與獨立測試組（ ITG）的創(chuàng)建相關的問題。 問：使用者輸入什么？它是怎么處理的？處理過程是如何通過界面表現(xiàn)出來的？產(chǎn)生的輸出是什么？ 答案略。 例子如下： 在它們引起“可撤銷的”損害之前抓住潛在的交互錯誤。逐步求精是通過連續(xù)精化過程細節(jié)層次來實現(xiàn)程序的開發(fā)。低耦合的好處是構件可以被修改但不會影響其他構件。設計者進行抽象，在那些需要擴展的功能與設計類本身之間起到緩沖區(qū)作用。在混合語言中（如 C++）構件可能是函數(shù)或類。 如果還沒有完成習題 ，請先完成它。 在軟件體系結構討論中，經(jīng)常會遇到體系結構風格、體系結構模式及框架（本書中沒有討論）等術語。任何面向對象的應用程序 。這些代表了房子的宏觀風格。他可能是提高了一個函數(shù)的處理速度或者在另一個系統(tǒng)中起到簡化組件的作用。 細化 2： 寫出大寫金額數(shù)的程序： 驗證金額數(shù)是否在允許范圍內(nèi)； 通過解析來確定美元單位 。 End if。 我們創(chuàng)建一個功能體系由此來提煉問題。然而，問題的 部分繼續(xù)組合，因為信息量超過了解一個人的能力不能無限期地進行下去，因此， 當問題非真 ，模塊化可以修改，但不能消除。此外，設計任務應用于一個項目可能不同于他們應用其他項目。設計的目標是創(chuàng)建一個可以正確地實現(xiàn)所有客戶需求并有好的用戶體驗的軟件模型。 表示行為建模時有兩種不同“狀態(tài)”類型，它們是什么？ 答：被動狀態(tài)展現(xiàn)出目標屬性的正確情況。再文法解析中，動詞時處理和可以被如 DFD 中的 Bubbles 描述的。 作為 視頻游戲的分析模型 ，道出了 大量的類。 c 一個小企業(yè)的簡單發(fā)票系統(tǒng)。 它與 需求模式的概念 相聯(lián)系。在這些域中哪些類型的需求是不可見的？提供一些例子。 最好的協(xié)商是爭取“雙贏”的結果，即利益相關者的“贏”在于獲得滿足客戶大多數(shù)需要的系統(tǒng)或產(chǎn)品，而作為軟 件團隊一員的“贏”在于按照實際情況、在可實現(xiàn)的預算和時間期限內(nèi)完成工作。這些初期步驟的成功實施可以達到一個雙贏的結果，這是繼續(xù)開展后續(xù)的軟件工程活動的關鍵。接下來使用各種圖表、矩陣和評估方法抽取 期望的需求并盡可能導出令人興奮的需求。 在 近 幾年中，雅各布森， Rumbaugh 和 Booch 制定的統(tǒng)一過程中框架使用 UML 的面向對象的軟件工程 。 質量太 差 可能導致 過多的 質量問題和 頻繁 的返工 。 在其他情況下，以漸進的方式可能是有意義的和螺旋模型的流動可能是有效率 ， 特殊過程模型具有許多的一個或多個傳統(tǒng)的特性 。 任何增量的處理流程 可 以 納入原型范式 。 詳細描述三個適用于采用原型模型的軟件項目。 解決辦法：所有的利益相關者被要求區(qū)分需求的優(yōu)先級，暫時保住利益相關者的優(yōu)先級最高或投 票的最多的需求從而解決這一問題。也就是說你得到了相互沖突的需求。 d） 討論 需 求 并 建立一個最終的的列表 。 第二章 在本章的介紹中， Baetjer 說過：“軟件過程為用戶和設計者之間、用戶和開發(fā)工具之間以及設計者和開發(fā)工具之間提供交互的途徑 [技術 ]”。 一個過程框架涉及大量的與客戶溝通 來 收集需求 ； 這個活動建立了一個軟件工程工作計劃 。 隨著軟件的普及，由于程序錯誤所帶來的公眾風險已經(jīng)成為一個愈加重要的問題。 思考 節(jié)中提到的 7 個軟件分類。為防止變 更引起軟件退化，請?zhí)岢鲆恍┯行У慕鉀Q措施。 e） 破壞高效 調(diào) 度 產(chǎn)生的 項目管理成果 和 無效的規(guī)劃 f）有時 裝備 部件質量差，導致額外的測試，設計和集成工作 和 管理額外的客戶關系 。 開發(fā)成本高 ： a）比 當時預期低得令人無法接受的質量，需要進行更多的測試，設計和實施工作 。另一個有趣的 方面 是使用諾依曼的 “風險 ”列在 SEN 中做 重點討論。 答： 典型的例子包括使用 “數(shù)字汽車儀表板 ”的軟件 ，賦予高科技，高品質的圖像 的軟件；如廣泛的消費類電子產(chǎn)品 的軟件；個人電腦， 工業(yè) 儀器 儀表和 機器的軟件。 答：軟件需要如此長的開發(fā)時間： a）設施不上線 b）開發(fā)工具并不如預期般運作 c）客戶提出的新要求，需要重新設計和返工 d）產(chǎn)品依賴于政府的規(guī)定，被意外更改。 d）開發(fā) 了 不需要 的 額外的軟件功能 而延長了開發(fā)日程安排 。 c）如果產(chǎn)品內(nèi)置沒有裝好 。 c)識別已知的需求 。在這不確定的今天 這些 “新的挑戰(zhàn) ”，無疑有 很大的影響（ 對于商務人士，軟件工程師和最終用戶來說 ） 然而，軟件工程師可以準備通過實例化一個過程， 使其 有足夠的靈活性和適應性，以適應劇烈變化的技術 ，這技術一定要在未來的很長一段時間被商業(yè) 規(guī)則所接受。 如 在航 空電子設備故障導致飛機墜毀 。 最后，它提供了 基于 評價的反饋 。 有新要求的需要 嗎？ 該產(chǎn)品比估計的大嗎？ 與預期的相比 模塊需要更多的測試，設計和實行工作 來糾正嗎？ b) 用戶詢問設計者的問題： 范圍明確 嗎？ 我們是否有 開發(fā) 工具和人 員開發(fā)軟件 所需的技能 ？ 定義的需求是正確的嗎？還有沒有額外的需要？ 特定領域的 軟件 產(chǎn)品比平時 的 花費更多的時間 嗎？ 該模塊是否需要更多的設計測試 ？ c）用戶對將要構建的軟件自問的問題： 軟件產(chǎn)品的范圍和目的是什么 ? 該產(chǎn)品比估計的大嗎？ 有優(yōu)秀的人可用嗎？ 工作人員可靠嗎有沒有具備所需要的技能？ 能保持 工作人 員的離職率足夠低 嗎？ d）設計者對于軟件產(chǎn)品和建造該產(chǎn)品采取的軟件過程自問的問題： 范圍和目的文件 是什么？ 要使用什么樣的工具 ？ 有什么目標和規(guī)避風險的優(yōu)先事項 ？ 對 風險分析，識別，估計，評價和管理會有什么樣的步驟 ？ 為溝通活動設計一些列的動作，選定一個動作作為其設計一個任務集。 b)要建立一個股權持有人要求 的 修訂清單 。 意圖： 此模式描述的方式 是 解決利益相關者之間 在 通信框架活動 中的 沖突 。 已知用途 /范例 ：必要的溝通是貫通整個軟件工程中。 如果將原型變成一個可發(fā)布的系統(tǒng)或產(chǎn)品，應該如何調(diào)整過程？ 答：如果將原