第1章軟件工程學概述基本概念軟件危機、軟件工程、軟件工程方法學、軟件生命周期、軟件過程、RUP、敏捷過程軟件危機的表現、產生的原因、怎樣消除結構化范型和面向對象范型的要點、優缺點軟件生命周期的組成及各階段的基本任務各類軟件生命周期模型的優缺點、適應范圍第2章可行性研究基本概念可行性研究、數據流圖、數據字典可行性研究的目的、任務數據流圖工具的實際應用第3章需求分析需求分析的原因、目的通常軟件系統有哪些需求？結構化分析方法建立的3種模型：數據模型、功能模型、行為模型。怎樣建立？各種圖形工具的實際應用。第5章總體設計軟件設計階段的任務軟件設計過程中應該遵循的基本原理和啟發規則模塊獨立的優點衡量模塊獨立性的標準：耦合和內聚如何提高模塊獨立性涉及到的原理、概念面向數據流的設計方法把數據流圖轉換成軟件結構第6章詳細設計什么是結構程序設計？人機界面的設計問題過程設計的工具程序流程圖、盒圖、PAD圖、判定樹、判定表、PDL面向數據結構的設計方法Jackson圖流圖和McCabe環路復雜度第7章實現編碼風格軟件測試的概念、目的、方法單元測試、集成測試、系統測試、驗收測試白盒測試技術：邏輯覆蓋和路徑覆蓋黑盒測試技術：等價類劃分和邊界值分析、錯誤推測法測試與調試的區別軟件可靠性的概念第8章維護軟件維護的定義和4類活動軟件可維護性、怎樣提高軟件產品的可維護性第9章面向對象方法學引論面向對象方法學的要點、優點面向對象方法學與傳統方法學的區別與聯系面向對象的一些基本概念對象、類、實例、消息、方法、屬性、封裝、繼承、多態、重載結構化分析方法建立的3種模型：對象模型、動態模型、功能模型。建立這些模型時主要使用哪些符號/工具？單項選擇（每小題2分）判斷對錯（每小題1分）簡答綜合題軟件工程中的方法技術的應用第一章軟件危機概念：指在計算機軟件的開發和維護過程中，所遇到的一系列嚴重問題。P1軟件危機表現：P21.對軟件開發成本和進度的估計常常很不正確2.用戶對“已完成的”軟件系統不滿意的現象經常發生3.軟件產品的質量往往靠不住4.軟件常常是不可維護的5.軟件通常沒有適當的文檔資料6.軟件成本在計算機系統總成本中所占的比例逐年上升7.軟件開發生產率提高的速度遠遠跟不上計算機應用迅速普及深入的趨勢軟件危機原因：P31.與軟件本身的特點有關2.與軟件開發與維護的方法不正確有關①軟件開發尚未完全擺脫手工開發方式。②軟件成本相當昂貴，主要依靠大量復雜的、高強度的腦力勞動。③軟件的開發和運行常常受到計算機系統的限制，對計算機系統有著不同程度的依賴性。怎樣消除軟件危機：P41、徹底消除“軟件就是程序”的錯誤觀念。2、充分認識到軟件開發是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目，不是個人獨立的勞動。3、推廣和使用在實踐中總結出來的軟件開發的成功技術和方法。4、開發和使用更好的軟件工具軟件工程概念：P5概括地說，軟件工程是指導計算機軟件開發和維護的一門工程學科。...p5軟件工程方法學：P9通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學也稱為范型。結構化范型和面向對象范型的要點：P91采用結構化技術（結構化分析、結構化設計和結構化實現）來完成軟件開發的各項任務；2把軟件生命周期劃分為若干個階段，按順序完成每個階段的任務；3每個階段開始和結束都有嚴格的標準，對任何兩個相鄰的階段而言，前一個階段的結束標準就是后一階段的開始標準；4每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審傳統方法學的優點：P10分解任務，分工合作，降低整個軟件開發工程的困難；采用科學的管理技術和良好的技術方法對每個階段成果都進行嚴格的審查。保證了軟件的質量。傳統方法學的缺點：P10把數據和操作人為地分離成兩個獨立的部分，增加了軟件開發與維護的難度。面向對象范型的要點:P101把對象（object）作為融合了數據及在數據上的操作行為的統一的軟件構件。2功能分解對象分解把所有對象都劃分成類（class）。3按照父類（或稱為基類）與子類（或稱為派生類）的關系，把若干個相關類組成一個層次結構的系統（也稱為類等級）。4對象彼此間僅能通過發送消息互相聯系。優點：P11降低了軟件產品的復雜性，提高了軟件的可理解性，簡化了軟件的開發和維護工作。促進了軟件重用。軟件生命周期：指軟件孕育、誕生、成長、成熟、衰亡的生存過程。軟件生命周期的組成P11,及各階段的基本任務：軟件生命周期由軟件定義（系統分析），軟件開發（具體設計和實現前一個時期定義的軟件），運行維護（使軟件持久的滿足用戶的需要）3個時期組成,每個階段任務1-7P11最下面軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的自工作步驟。P14瀑布模型（開發需求明確的軟件）P15優點：可強迫開發人員采用規范的方法；嚴格地規定了每個階段必須提交的文檔；要求每個階段的所有產品都必須經過質量保證小組的仔細驗證；缺點：無法解決軟件需求不明確或不準確的問題；可能導致最終開發的產品不能真正滿足用己戶需要。瀑布模型比較適合開發需求明確的軟件?？焖僭湍Ｐ停ㄐ枨蟛惶鞔_）P16優點：1、通常能反映用戶真實需求；2、軟件產品的開發基本上是線性順序進行的。增量（漸增）模型P17優點：能在較短的時間內，提供可完成部分工作的初步產品給用戶；用戶有較為充裕的時動間學習和適應新產品。缺點：對開發人員技術能力要求較高，要求能從系統整體出發正確劃分增量構件，并進行分手別開發，最后能很好地集成這些構件。螺旋模型（適合大型軟件開發）P19優點：強調可選方案和約束條件，有利于已有軟件的重用，也有助于把軟件質量作為軟件開豐發的一個重要目標；減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風衣險；維護是一個周期，與開發并沒有本質區別缺點：需要開發人員具有相當豐富的風險評估經驗和專門知識；進行風險分析的費用可能較足大。RUP概念：P22稱RUP或UP基于構件(component)，在UML基礎上發展起來的，“用例驅動，以架構為核食心，迭代并且增量”。在某種程度上，統一過程嘗試從傳統軟件過程中挖掘最好的特征和性懶質，但是以敏捷開發中許多好的原則來實現。敏捷過程概念：P25敏捷過程是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效惰率和響應能力。根據下述4個價值觀提出的軟件過程統稱為敏捷過程1開發人員的素質及相互間的交互與協作比過程和工具更重要2可以工作的軟件比面面俱到的文檔更重要3與客戶的合作比合同談判更重要4及時響應變化比死板地遵循計劃更重要第二章可行性研究：開發一個基于計算機的系統通常都受到資源（人力、財力、設備等）和時間上的限制，可是行性研究主要從經濟、技術、法律等方面分析所給出的解決方案是否可行，能否在規定的資大源和時間的約束下完成?？尚行匝芯磕康模河米钚〉拇鷥r在盡可能短的時間內確定問題是否能夠解決。不是解決問忌題，而是確定問題是否值得去解決。P35可行性研究的任務：P351.技術可行性：使用現有的技術能實現這個系統嗎？主要考慮：開發風險；資源；相關技術的發展2.經濟可行性：這個系統的經濟效益能超過它的開發成本嗎？系統經濟效益=新系統增加的收入＋新系統節省的費用考慮：成本/效益分析、長期的公司經營策略、對其他單位或產品的影響、開發所需的成本和資源、潛在的市場前景3.操作可行性：系統的操作方式在用戶組織內行得通嗎？用戶使用可能性；時間進度可行性；組織和文化上的可行性4.其他：法律可行性、社會效應、管理問題等可行性研究的主要任務是“了解客戶的要求及現實環境，從技術、經濟和社會因素等三方面研究并論證本軟件項目的可行性，編寫可行性研究報告，制定初步項目開發計劃?？尚行匝芯康淖罡救蝿帐菍浖_發以后的行動方針提出建議?？尚行匝芯克枰臅r間長短取決于工程的規模。數據流圖描繪系統的邏輯模型，圖中無具體的物理元素，只是描繪信息在系統中流動和處理的情況,是一種圖形化技術P40數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。P47數據流圖工具的實際應用（看書例子）P44第三章軟件需求指用戶對所開發的軟件在功能、性能、環境、可靠性等各方面的要求。需求分析主要回答待開發的系統必須“做什么”，并用《軟件需求規格說明書》的形式準確、詳細、規范地表達出來?？梢哉f需求分析是做系統之前必做的。軟件系統有哪些需求：P56①功能需求。②性能需求。③可靠性和可用性需求。④出錯處理需求。⑤接口需求。⑥約束。⑦逆向需求。⑧將來可能提出的要求。結構化分析是面向數據流進行分析的方法，主要建立以下幾種模型：實體-聯系圖(Entity-RelationshipDiagram,E-R圖)來創建數據模型，描述系統中所有重要的數據對象。數據流圖（DataFlowDiagram,DFD）：用來創建功能模型，描述了信息流和數據轉換。狀態轉換圖（State-TransitionDiagram,STD）用來創建行為模型，描述系統狀態如何響應外部事件，而進行轉換。各種圖形工具的實際應用。和第3章的習題ER圖P64狀態轉換圖P66-67數據流圖例P44第五章軟件設計兩個階段的任務P91第一階段：概要設計（總體設計）1方案設計，設想各種可能方案，分析選出最佳方案并制定相應的實現計劃。2軟件體系結構設計，確定軟件系統中每個程序是由哪些模塊組成的，以及它們之間的關系第二階段：詳細設計（過程設計）過程設計設計軟件體系結構中所包含的每個模塊的實現算法.1數據設計，設計軟件中所需要的數據結構。2接口設計，設計軟件內部各模塊之間、軟件與協作系統之間以及軟件與使用它的人之間的通信方式軟件設計過程中應該遵循的基本原理P941模塊化2抽象3逐步求精4信息隱蔽和局部化5模塊獨立模塊化的優點：模塊化是軟件解決復雜問題所具備的手段，可降低軟件復雜性，減少開發工作量，從而降低開發成本，提高軟件生產率，是模塊化的依據。P97eq\o\ac(○,1)有效的模塊化的軟件比較容易開發出來.eq\o\ac(○,2)獨立的模塊化比較容易測試和維護.衡量模塊獨立性的兩個準則：①耦合性（coupling)衡量不同模塊彼此間互相依賴(連接)的緊密程度。②內聚性（cohesion)衡量模塊內部各個元素彼此結合的緊密程度。P97提升模塊獨立性改進原則的方法：高內聚，低耦合！P99啟發規則：①改進軟件結構，提高模塊獨立性②模塊規模適中③深度、寬度、扇出和扇入適中④將模塊的影響限制在控制范圍內⑤降低模塊接口的復雜性⑥設計單入口單出口的模塊⑦模塊功能應該可預測P99面向數據流的設計方法：面向數據流設計（DFOD）是與數據流分析（DFA）對應的結構化軟件設計技術。面向數據流的設計將得到以數據流圖為基礎的軟件模塊結構圖P104(區別)變換型數據流基本模型：特點：具有明確的傳入、變換（或稱主加工）和傳出界面的DFD事務型數據流基本模型：事務型數據流圖中存在一個事務中心（也就是數據處理、加工中心）它將輸入分離成若干個發散的數據流，形成許多活動路徑，并根據輸入值選擇其中一條路徑。變換設計就是從變換型數據流圖映射出軟件模塊結構的過程，也稱以變換為中心的設計。變換設計的基本方法有兩步：1）分解第一層模塊結構2）分別設計輸入、輸出和處理的下層模塊結構P105最下第六章結構程序設計：如果一個程序的代碼塊僅僅通過順序、選擇和循環這3種基本控制結構進行連接，而且每個代碼塊只有一個入口和一個出口，則稱這個程序是結構化的。P118人機界面設計問題：①系統響應時間②用戶幫助信息③出錯信息處理④命令交互P119過程設計的工具：圖形工具:程序流程圖、盒圖、PAD圖、表格工具:判定樹、判定表、語言工具:PDLP124-128過程設計：設計軟件體系結構中所包含的每個模塊的實現算法過程設計：應該在數據設計、體系結構設計和接口設計完成之后進行，它是詳細設計階段應該完成的主要任務1.程序流程圖又稱程序框圖。以圖形方式說明系統中的控制流，是歷史最悠久、使用最廣泛的一種描述程序邏輯結構的工具。2.盒圖:出于要有一種不違背結構程序設計精神的圖形工具的考慮，Nassi和Shneiderman提出用盒圖代替傳統的流程圖，簡稱為N一S圖。3.PAD圖:日立公司發明。用二維樹形結構的圖來表示程序的控制流，控制流程自上而下，從左往右地執行。4.判定表能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。5.判定樹是判定表的變種，能清晰表示復雜的條件組合與操作之間的關系，形式簡單，不需要做任何說明，是常見的系統分析工具。6.PDL也稱偽碼（pseudocode)，是一種介于自然語言和形式化語言之間的語言，用于描述功能模塊的算法設計和處理細節的語言。面向數據結構的設計方法的最終目標是得出對程序處理過程的描述，適合于在詳細設計階段使用，即，在完成了軟件結構設計之后，可以使用面向數據結構的方法來設計每個模塊的處理過程。Jackson圖:順序結構:順序結構的數據由一個或多個數據元素組成，每個元素按確定次序出現一次。選擇結構:選擇結構的數據包含兩個或多個數據元素，每次使用這個數據時按一定條件從這些數據元素中選擇一個。重復結構:重復結構的數據，根據使用時的條件由一個數據元素出現零次或多次構成。P130P138流圖轉換一個程序的環形復雜度取決于它的程序圖(流圖)包含的判定結點的數量.環路復雜度會算第七章編碼風格是指程序員編制程序時所表現出來的特點、習慣、邏輯思路等。P147軟件測試：1是為了發現錯誤而執行程序的過程。2發現錯誤是為了更正錯誤，最終得到一個高質量的軟件系統。P150軟件測試目的：1測試是為了發現錯誤而執行程序的過程2好的測試用例是極可能發現至今為止尚未發現的錯誤的測試方案；3成功的測試是發現了至今未發現的錯誤的測試；4總之，測試的目的是以最少的時間和人力，系統地找出軟件中潛在的各種錯誤和缺陷；測試附帶的收獲是它能證明軟件的功能和性能與需求說明相符合。P151測試方法：軟件測試方法一般分為：靜態測試和動態測試。靜態測試：是指被測程序不在機器上運行，采用人工檢測和計算機輔助靜態分析的手段對程序進行檢測。動態測試：是指通過運行程序發現錯誤，又分黑盒測試和白盒測試兩種。已知產品應該具有的功能，可以通過黑盒測試來檢驗每個功能是否符合設計要求。已知產品的內部工作過程，可以通過白盒測試來檢驗每種內部操作是否按要求的規定正常進行。單元測試：又稱模塊測試，需要從程序的內部結構出發設計測試用例。測試目的：發現模塊內部可能存在的差錯測試依據：詳細設計說明書和源程序清單測試方法：白盒測試為主，黑盒測試為輔，多個模塊并行進行。P153集成測試：在單元測試之后，將模塊組裝成系統，為發現并排除模塊在連接中可能出現的問（主要與接口有關），而進行的測試。P156驗收測試：有些文獻中驗收測試也稱確認測試。驗證軟件的功能、性能及其它特性是否與用戶的要求一致。P160白盒測試是基于代碼的針對被測對象內部是如何進行工作的測試，也稱作結構測試或邏輯驅動測試或基于程序的測試。P162邏輯覆蓋是以程序內部的邏輯結構為基礎設計測試用例的技術。P162路徑覆蓋是指：選取足夠多的測試用例，使得程序的每條可能路徑都至少執行一次。P165等價劃分基本思想：把所有可能的輸入數據（包括有效或無效的），劃分成若干數據類（等價類），然后從每個數據類中選取少數有代表性的數據做為測試用例。這種方法完全不考慮程序的內部結構，只依據程序的規格說明來設計測試用例。P172邊界值分析方法思想：確定邊界之后，選取正好等于、剛剛大于或剛剛小于邊界的值做為測試數據，而不是選取等價類中典型值或任意值做為測試數據。P175錯誤推測基本思想：列舉程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。依靠經驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例。P175測試與調試區別P176-178軟件測試是軟件測試人員和程序員都參與的一項工作，是貫穿整個生命周期的，只需要發現軟件的錯誤，而軟件調試主要是程序員自己參與，對程序（設計、編碼）進行修改、排除錯誤，主要是在開發階段。第八章軟件可靠性是程序在給定的時間點，按照規格說明書的規定，成功地運行的概率。P179可靠性和可用性的主要差別：可靠性意味著在0到t這段時間間隔內系統沒有失效；可用性只意味著在時刻t，系統是正常運行的軟件維護P189是指在軟件運行或維護階段對軟件產品所進行的修改。分為四類：①改正性維護為了識別和糾正在使用過程中暴露出來的錯誤②適應性維護為了適應外部環境或數據環境變化③完善性維護為了改進原有的軟件，滿足用戶提出的新的功能與性能要求④預防性維護為了改進將來的可維護性和可靠性軟件可維護性的定義軟件可維護性指糾正軟件系統出現的錯誤和缺陷，以及為滿足新的要求進行修改、擴充或壓縮的容易程度。P194（增加）可維護性的度量1可理解性：人們通過閱讀源代碼和相關文檔，了解程序功及其如何運行的容易程度。2可靠性：表明一個程序按照用戶的要求和設計目標，在給定的一段時間內正確執行的概率。3可測試性：表明診斷和測試的容易程度。4可修改性：表明程序容易修改的程度。5可移植性：表明把程序從一種計算環境轉移到另一種計算環境的難易程度。6可重用性：指同一個軟件（或軟件成份）不做修改或稍加改動，就可以在不同環境中多次重復使用。P195第九章面向對象技術的要點：①任何客觀的事物或實體都是對象。對象組成客觀世界，復雜的對象可以由簡單的對象組成。②具有相同數據和操作的對象可以歸并為一個類（class)，對象是對象類的一個實例。③類可以派生出子類，子類繼承父類的全部特性（數據和操作），又可以有自己的新特性。子類與父類形成類的層次結構。④對象之間通過消息傳遞相互聯系。P204面向對象方法學的優點：1與人類習慣的思維方法一致2穩定性好3可重用性好4較易開發大型軟件產品5可維護性好P205面向對象的一些基本概念對象、類、實例、消息、方法、屬性、封裝、繼承、多態、重載（書）P209-215對象模型描述系統內部對象的靜態結構，包括對象本身的定義、對象的屬性和操作、以及對象與其它對象之間的關系。UML中，對象模型通常由“類圖”組成。（例子看書）類圖描述類及類與類之間的靜態關系，類圖是創建其他UML圖的基礎。一個系統可以由多張類圖來描述，一個類也可以出現在幾張類圖中。P216動態模型表示瞬時的、行為化的系統的“控制”性質，即對象的動態行為。UML中，用狀態圖描述對象可能的狀態及其轉換，關心對象在某過程中的經歷。通過狀態圖來描繪對象的狀態、觸發狀態轉換的事件以及對象的行為。P223功能模型表示變化的系統的“功能”性質，它指明了系統應該“做什么”，因此更直接地反映了用戶對目標系統的需求。UML中用用例圖建立系統的功能模型。在UML中把以用例圖建立起來的系統模型稱為用例模型。用例模型描述的是外部行為者(actor）所理解的系統功能，是其他視圖的核心和基礎。P224三種模型之間的關系:1對象模型定義了做事情的實體，描述了動態模型、功能模型所操作的數據結構。對象模型中的操作對應于動態模型中事件和功能模型中的函數。2動態模型描述了對象的控制結構，它明確規定了什么時候(即在何種狀態下接受了什么事件觸發做;。3功能模型指明了系統應該”做什么”，由數據流圖和用例圖組成，描述了對象模型中操作的含義、動態模型中動作的意義以及對象模型中約束的意義。傳統軟件工程方法學:以面向過程的結構化程序設計為基礎；遵循“程序=數據結構+算法”的思路；由“追求技巧與效率”到“清晰第一，效率第二”缺點：1不太適應規模大、特別復雜的項目；2難以解決軟件重用的問題3難以適應需求的變化；4難以徹底解決維護問題。區別與聯系面向對象軟件工程按人類習慣的思維方法，以現實世界中客觀存在的事物（即對象）為中心來思考和認識問題。采用的思想方法與原則：抽象、分類、繼承、聚合、封裝等以易于理解的方式表達軟件系統，建立問題域模型，使設計出的軟件盡可能直接地描述現實世界，具有更好的可維護性。第一章1-1什么是軟件危機?是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。1-3什么是軟件工程?是指導計算機軟件開發和維護的一門工程學科。1-4簡述結構化范型和面向對象范型的要點，并分析它們的優缺點。目前使用得最廣泛的軟件工程方法學（2種）：1.傳統方法學：也稱為生命周期方法學或結構化范型。優點：把軟件生命周期劃分成基干個階段，每個階段的任務相對獨立，而且比較簡單，便于不同人員分工協作，從而降低了整個軟件開發過程的困難程度。缺點：當軟件規模龐大時，或者對軟件的需求是模糊的或會承受時間而變化的時候，開發出的軟件往往不成功；而且維護起來仍然很困難。2.面向對象方法學：優點：降低了軟件產品的復雜性；提高了軟件的可理解性；簡化了軟件的開發和維護工作；促進了軟件重用。1-6什么是軟件過程?它與軟件工程方法學有何關系?軟件過程：是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟軟件工程方法學：通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學，也稱范型1-7什么是軟件生命周期模型，試比較瀑布模型，快速原型模型，增量模型，和螺旋模型的優缺點，說明每種模型的適用范圍。軟件生命周期由軟件定義、軟件開發和運行維護3個時期組成，每個時期又進一步劃分成若干個階段。生命周期模型規定了把生命周期劃分成哪些階段及各個階段的執行順序，因此，也稱為過程模型。瀑布模型的優點：1.可強迫開發人員采用規范的方法；2.嚴格規定了每個階段必須提交的文檔；3.要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。瀑布模型的缺點：1.在軟件開發初期，指明用戶全部需求是困難的；2.需求確定后，經過一段時間才得到軟件最初版本；3.完全依賴規格說明，導致不能滿足用戶需求。適用中小型項目。快速原型模型的優點：1滿足用戶需求程度高；2用戶的參與面廣；3返工現象少快速原型模型的缺點：不適用大型軟件的開發適用于小型項目。增量模型的優點：1短期內可以交付滿足部分用戶需求的功能產品；2逐步增加功能可以讓用戶去適應新產品；3開放式的軟件可維護性比較好；4開始第一構件前，已經完成需求說明。增量模型的缺點：1對現有產品功能造成破壞；2意義上的矛盾適用于中型軟件的開發螺旋模型的優點：1集成了瀑布模型、快速原型模型、增量模型的優點；2支持用戶需求動態變化；3需求分析與軟件實現緊密聯系相互依賴；4原型作為刑式的可執行的需求規格說明，即利用用戶和開發人員共同理解，又可作為后續開發的基礎；5為用戶參與決策提供方便；6提高目標軟件的適應能力；7降低風險；8在大型軟件開發過程中充分發揮優勢。Z螺旋模型的缺點：1迭代次數影響開發成本，延遲提價時間；2找不到關鍵改進點，人才、物力、財力時間引起無謂消耗；3成于風險分析，敗于風險分析。適用于內部開發的大規模軟件項目。1-8：為什么說噴泉模型叫好的體現了面向對象軟件開發過程無縫和迭代的特性？因為使用面向對象方法學開發軟件時，各個階段都使用統一的概念和表示符號，因此，整個開發過程都是吻合一致的，或者說是無縫連接的，這自然就很容易實現各個開發步驟的反復多次迭代，達到認識的逐步深化，而噴泉模型的則很好的體現了面向對象軟件開發過程迭代和無縫的特性。1-9：試討論Rational統一過程的優缺點優點：提高了團隊生產力，在迭代的開發過程、需求管理、基于組建的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面、針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模版和工具指導，并確保全體成員共享相同的知識基礎。它簡歷了簡潔和清晰的過程結構，為開發過程提供較大的通用性。缺點：RUP只是一個開發過程，并沒有涵蓋軟件過程的全部內容，例如它缺少關于軟件運行和支持等方面的內容，此外，它沒有支持多項目的開發結構，這在一定程度上降低了在開發組織內大范圍實現重用的可能性。1-10Rational統一過程主要適用于何種項目？大型的需求不斷變化的復雜軟件系統項目1-11：說明敏捷過程的適用范圍適用于商業競爭環境下對小型項目提出的有限資源和有限開發時間的約束。1-12說明微軟過程的適用范圍適用于商業環境下具有有限資源和有限開發時間約束的項目的軟件過程模式。第二章2-1在軟件開發的早期階段為什么要進行可行性分析研究？應該從哪些方面研究目標系統的可行性？可行性分析是要進行一次大大壓縮簡化系統分析和設計過程，避免時間、資源、人力和金錢的浪費。技術上的可行性——使用現有的技術能實現這個系統嗎？經濟上的可行性——這個系統的經濟效益能超過它的開發成本嗎？（投資與效益）操作可行性——系統的操作方式在這個用戶組織內行得通嗎？社會、政策允許的可行性2-2為方便儲戶，某銀行擬開發計算機儲蓄系統。儲戶填寫的存款單或取款單由業務員鍵入系統，如果是存款，系統記錄存款人姓名、住址、存款類型、存款日期、利率等信息，并印出存款單給儲戶；如果是取款，系統計算利息并印出利息清單給儲戶。請畫出此系統的數據流圖。2-3為方便旅客，某航空公司擬開發一個機票預定系統。旅行社把預訂機票的旅客信息（姓名、性別、工作單位、身份證號碼、旅行時間、旅行目的地等）輸入進該系統，系統為旅客安排航班，印出取票通知和賬單，旅客在飛機起飛的前一天憑取票通知和賬單交款取票，系統核對無誤即印出機票給旅客。請畫出系統的數據流圖。2-4目前住院病人主要由護士護理，這樣做不僅需要大量護士，而且由于不能隨時觀察危險病人的病情變化，還可能會延誤搶救時機。某醫院打算開發一個以計算機為中心的患者監護系統，試寫出問題定義，并且分析開發這個系統的可行性。醫院對患者監護系統的基本要求是隨時接受每個病人的生理信號（脈搏、體溫、血壓、心電圖等），定時記錄病人情況以及形成患者日志，當某個病人的生理信號超出醫生規定的安全范圍時向值班護士發出警告信息，此外，護士在需要時還可以要求系統印出某個指定病人的病情報告。請畫出系統的數據流圖。2-5北京某高?？捎玫碾娫捥柎a由以下幾類：校內電話號碼由4位數字組成，第一位數字不是零；校外電話又分為本市電話和外地電話兩類,撥校外電話先撥0，若是本地電話再接著撥8位數字（固話第一位不是0）或11位數字（移動電話第一位為1）；若是外地電話，則撥3位區碼再撥8位電話號碼（固話第一位不是0），或撥0再撥11位數字（移動電話第一位為1）。請用數據定義的方法，定義上述電話號碼。電話號碼=[校內號碼|校外號碼]校內號碼=非0數字+3{數字}3校外號碼=0+[本地號碼|外地號碼]本地號碼=[固話號碼|手機號碼]固話號碼=非0數字+7{數字}7手機號碼=1+10{數字}10外地號碼=[外地固話號碼|外地手機號碼]外地固話號碼=3{數字}3+固話號碼外地手機號碼=0+手機號碼非0數字=[1|2|3|4|5|6|7|8|9]第三章1、為什么要進行需求分析？通常對軟件系統有哪些需求？答：為了開發出真正滿足用戶需求的軟件產品，準確定義未來系統的目標，確定為了滿足用戶的需要系統必須做什么，就必須要進行準確的需求分析。通常對軟件系統的需求有：功能需求；性能需求；可靠性和可用性需求；出錯處理需求；接口需求；約束；逆向需求；文檔需求；數據需求等等。2、銀行計算機儲蓄系統的工作過程大致如下：儲戶填寫的存款單或取款單由業務員鍵入系統，如果是存款則系統記錄存款人姓名、住址、身份證號碼等存款信息，并打印出存款存單給儲戶；如果是取款且存款時留有密碼，則系統首先核對儲戶密碼，若密碼正確或存款時未留密碼，則系統計算利息并打印出利息清單給儲戶。用數據流圖描述本系統的功能，并用ER圖描繪系統中的數據對像。6、復印機的工作過程大致如下：未接到復印命令時處于閑置狀態，一旦接到復印命令則進入復印狀態，完成一個復印命令規定的工作后又回到閑置狀態，等待下一個復印命令；如果執行復印命令時發現沒紙，則進入缺紙狀態，發出警告，等待裝紙，裝滿紙后進入閑置狀態，準備接收復印命令；如果復印時發生卡紙故障，則進入卡紙狀態，發出警告等待維修人員來排除故障，故障排除后回到閑置狀態。請用狀態轉換圖描繪復印機的行為。從問題陳述可知，復印機的狀態主要有“閑置”、“復印”、“缺紙”和“卡紙”。引起狀態轉換的事件主要是“復印命令”、“完成復印命令”、“發現缺紙”、“裝滿紙”、“發生卡紙故障”和“排除了卡紙故障第五章5-4美國某大學有200名教師，校方與教師工會剛剛簽訂一項協議