軟件工程課后作業(yè)

1、第一章1.1答：軟件危機是指在計算機軟件開發(fā)、使用與維護過程中遇到的一系列嚴重問題和難題。它包括兩方面：如何開發(fā)軟件，已滿足對軟件日益增長的需求；如何維護數(shù)量不斷增長的已有軟件。軟件危機的典型表現(xiàn)：(1) 對軟件開發(fā)成本和進度的估計常常很不準確。常常出現(xiàn)實際成本比估算成本高出一個數(shù)量級、實際進度比計劃進度拖延幾個月甚至幾年的現(xiàn)象。而為了趕進度和節(jié)約成本所采取的一些權(quán)宜之計又往往損害了軟件產(chǎn)品的質(zhì)量。這些都降低了開發(fā)商的信譽，引起用戶不滿。(2) 用戶對已完成的軟件不滿意的現(xiàn)象時有發(fā)生。(3) 軟件產(chǎn)品的質(zhì)量往往是靠不住的。(4) 軟件常常是不可維護的。(5) 軟件通常沒有適當?shù)奈臋n資料。文檔資

2、料不全或不合格，必將給軟件開發(fā)和維護工作帶來許多難以想象的困難和難以解決的問題。(6) 軟件成本、軟件維護費在計算機系統(tǒng)總成本中所占比例逐年上升。(7) 開發(fā)生產(chǎn)率提高的速度遠跟不上計算機應用普及的需求。軟件危機出現(xiàn)的原因：(1) 來自軟件自身的特點：是邏輯部件，缺乏可見性；規(guī)模龐大、復雜，修改、維護困難。(2) 軟件開發(fā)與維護的方法不當：忽視需求分析；認為軟件開發(fā)等于程序編寫；輕視軟件維護。(3) 供求矛盾將是一個永恒的主題：面對日益增長的軟件需求，人們顯得力不從心。1.2答：在軟件開發(fā)的不同階段進行修改付出的代價是很不相同的，在早期引入變動，涉及的面較少，因而代價也比較低；在開發(fā)的中期，軟

3、件配置的許多成分已經(jīng)完成，引入一個變動要對所有已完成的配置成分都做相應的修改，不僅工作量大，而且邏輯上也更復雜，因此付出的代價劇增；在軟件“已經(jīng)完成”是在引入變動，當然付出的代價更高。一個故障是代碼錯誤造成的，有時這種錯誤是不可避免的，但要修改的成本是很小的，因為這不是整體構(gòu)架的錯誤。1.3答：1993年IEEE的定義：軟件工程是： 把系統(tǒng)的、規(guī)范的、可度量的途徑應用于軟件開發(fā)、運行和維護過程，也就是把工程應用于軟件； 研究中提到的途徑。軟件工程的本質(zhì)特征：(1) 軟件工程關注于大型程序(軟件系統(tǒng))的構(gòu)造(2) 軟件工程的中心課題是分解問題，控制復雜性(3) 軟件是經(jīng)常變化的，開發(fā)過程中必須考

4、慮軟件將來可能的變化(4) 開發(fā)軟件的效率非常重要，因此，軟件工程的一個重要課題就是，尋求開發(fā)與維護軟件的更好更有效的方法和工具(5) 和諧地合作是開發(fā)軟件的關鍵(6) 軟件必須有效地支持它的用戶在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人(完成一些工作)消除軟件危機的途徑：(1) 對計算機軟件有一個正確的認識(軟件程序）(2) 必須充分認識到軟件開發(fā)不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程項目(3) 推廣使用在實踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法(4) 開發(fā)和使用更好的軟件工具1.4答：1.傳統(tǒng)方法學：也稱為生命周期

5、方法學或結(jié)構(gòu)化范型。優(yōu)點：把軟件生命周期劃分成基干個階段，每個階段的任務相對獨立，而且比較簡單，便于不同人員分工協(xié)作，從而降低了整個軟件開發(fā)過程的困難程度。缺點：當軟件規(guī)模龐大時，或者對軟件的需求是模糊的或會承受時間而變化的時候，開發(fā)出的軟件往往不成功；而且維護起來仍然很困難。2.面向?qū)ο蠓椒▽W：優(yōu)點：降低了軟件產(chǎn)品的復雜性；提高了軟件的可理解性；簡化了軟件的開發(fā)和維護工作；促進了軟件重用。1.5答：(1) 存儲容量需求M=4080e0.28（1985-1960）=4474263（字）存儲器價格P=0.048*0.72（1985-1974）*4474263=5789美元(2) 需要工作量447

6、4263/200=22371（人/月）指令成本22371*4000=89484000美元(3) 需求估計M=4080e0.28（1995-1960）=73577679字存儲器價格0.003*32*0.72（1995-1974）*73577679=7127美元工作量73577679/600=122629(人/月）成本122629*6000=735776790美元1.6答：軟件過程是為了開發(fā)出高質(zhì)量的軟件產(chǎn)品所需完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟。軟件工程方法學：通常把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合稱為方法學，也稱范型。軟件過程是軟件工程方法學的3個重要組成部

7、分之一。1.7答：軟件生命周期模型是跨越整個生存期的系統(tǒng)開發(fā)、運作和維護所實施的全部過程、活動和任務的結(jié)構(gòu)框架。瀑布模型:優(yōu)點：它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好得多。缺點：(1) 實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。(2) 經(jīng)常情況下客戶難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。(3) 客戶要等到開發(fā)周期的晚期才能看到程序運行的測試版本，而在這時發(fā)現(xiàn)大的錯誤時，可能引起客戶

8、的驚慌，而后果也可能是災難性的?？焖僭湍Ｐ?優(yōu)點：使用戶能夠感受到實際的系統(tǒng)，使開發(fā)者能夠快速地構(gòu)造出系統(tǒng)的框架。缺點：產(chǎn)品的先天性不足，因為開發(fā)者常常需要做實現(xiàn)上的折中，可能采用不合適的操作系統(tǒng)或程序設計語言，以使原型能夠盡快工作。 增量模型:優(yōu)點：(1) 人員分配靈活，剛開始不用投入大量人力資源，當核心產(chǎn)品很受歡迎時，可增加人力實現(xiàn)下一個增量。(2) 當配備的人員不能在設定的期限內(nèi)完成產(chǎn)品時，它提供了一種先推出核心產(chǎn)品的途徑，這樣就可以先發(fā)布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用。缺點：(1) 至始至終開發(fā)者和客戶糾纏在一起，直到完全版本出來。(2) 適合于軟件需求不明確、設計方案有一定

9、風險的軟件項目。該模型具有一定的市場。螺旋模型:優(yōu)點：對于大型系統(tǒng)及軟件的開發(fā)，這種模型是一個很好的方法。開發(fā)者和客戶能夠較好地對待和理解每一個演化級別上的風險。缺點：(1) 需要相當?shù)娘L險分析評估的專門技術(shù)，且成功依賴于這種技術(shù)。(2) 很明顯一個大的沒有被發(fā)現(xiàn)的風險問題，將會導致問題的發(fā)生，可能導致演化的方法失去控制。(3) 這種模型相對比較新，應用不廣泛，其功效需要進一步的驗證。該模型適合于大型軟件的開發(fā)1.8答：因為使用面向?qū)ο蠓椒▽W開發(fā)軟件時，各個階段都使用統(tǒng)一的概念和表示符號，因此，整個開發(fā)過程都是吻合一致的，或者說是無縫連接的，這自然就很容易實現(xiàn)各個開發(fā)步驟的反復多次迭代，達到認

10、識的逐步深化，而噴泉模型則很好的體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。1.9答：優(yōu)點:提高了團隊生產(chǎn)力，在迭代的開發(fā)過程、需求管理、基于組建的體系結(jié)構(gòu)、可視化軟件建模、驗證軟件質(zhì)量及控制軟件變更等方面、針對所有關鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準則、模版和工具指導，并確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。缺點：RUP只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內(nèi)容，例如它缺少關于軟件運行和支持等方面的內(nèi)容，此外，他沒有支持多項目的開發(fā)結(jié)構(gòu)，這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實現(xiàn)重用的可能性。1.10答：大型的需求不斷變化的復雜軟

11、件系統(tǒng)項目1.11答：適用于商業(yè)競爭環(huán)境下對小型項目提出的有限資源和有限開發(fā)時間的約束1.12適用于商業(yè)環(huán)境下具有有限資源和有限開發(fā)時間約束的項目的軟件過程模式.第二章2.2答：如果是存款，儲戶填寫存款單，然后交給業(yè)務員鍵入系統(tǒng)，同時系統(tǒng)還要記錄存款人姓名、住址（或電話號碼）、身份證號碼、存款類型、存款日期、利率等信息，完成后由系統(tǒng)打印存款單給儲戶。如果是取款，儲戶填寫取款單，然后交給業(yè)務員，業(yè)務員把取款金額輸入系統(tǒng)并要求儲戶輸入密碼以確認身份，核對密碼正確無誤后系統(tǒng)計算利息并印出利息清單給儲戶。為了滿足儲戶的需求，該系統(tǒng)需要迅速的對用戶的要求做出反饋，要對用戶輸入的信息作出最快的處理，所以就

12、需要很大的主存容量，以及強大的數(shù)據(jù)庫支持。由于是所面向的用戶是廣泛的儲蓄用戶群，所以需要系統(tǒng)強大的安全性能支持。可行性研究方法條件、假定和限制建議開發(fā)軟件運行的最短壽命：5年進行系統(tǒng)方案選擇比較的期限：2個月經(jīng)費來源和使用限制：定制銀行硬件、軟件、運行環(huán)境和開發(fā)環(huán)境的條件和限制：銀行中心擁有大型機以及用來支持的數(shù)據(jù)庫，各個銀行網(wǎng)點都有安好的PC機，安裝有Windows2000及以上的操作系統(tǒng)。建議開發(fā)軟件投入使用的最遲時間：開發(fā)完成后試運行1個月?？尚行匝芯糠椒ㄍㄟ^與銀行熟練業(yè)務員進行深入討論，制定詳細用戶調(diào)查問卷，真正了解用戶以及銀行業(yè)務員的實際需求，根據(jù)業(yè)務員提供的信息以及問題定義再綜合調(diào)

13、查問卷中用戶提出的意見進行改進。最終確定項目需要解決的問題，并確定問題能不能被解決。決定可行性的主要因素1）項目開發(fā)成本2）所需設備置辦成本3）技術(shù)是否能滿足需求4）操作人員的熟練程度5）資源有效性對現(xiàn)有系統(tǒng)的分析1處理流程和數(shù)據(jù)流程系統(tǒng)流程圖存款流程圖：取款流程圖：數(shù)據(jù)流圖：2工作負荷當前大多數(shù)銀行所使用的銀行儲蓄系統(tǒng)在辦理業(yè)務時手續(xù)繁瑣，人工業(yè)務操作過多，辦理一個客戶的業(yè)務就需耗費較長的時間，其他客戶只有等待。這樣太浪費時間，需要大量的業(yè)務員處理客戶業(yè)務。特別是在節(jié)假日人流高峰期，導致工作效率非常低，且出錯率高，以致客戶等待辦理手續(xù)過長感到不耐煩，降低了銀行效率。這也給銀行工作人員增加了非

14、常大的負擔和額外的工作負荷；同時業(yè)務員增多，銀行費用支出多，給銀行公司的發(fā)展帶來嚴重的制約和壓力。3費用支出運行現(xiàn)有系統(tǒng)所需要的費用支出包括：銀行業(yè)務員及其他工作人員的工資，系統(tǒng)維護所需資金，4人員需要大量的業(yè)務員、客服人員，系統(tǒng)維護人員以及其他工作人員。5設備現(xiàn)有系統(tǒng)所需要的設備有：打印機、PC機、電腦。6局限性工作效率底下，不能符合大量群眾的及時需求，給群眾的生活帶來不便。這是現(xiàn)有系統(tǒng)辦理業(yè)務的流程中出現(xiàn)的一個嚴重問題。為了解決這一問題，讓人們再辦理銀行業(yè)務更加方便快捷，我們急需開發(fā)一個更為高效的銀行計算機儲蓄系統(tǒng)，讓儲蓄業(yè)務不用再排隊。（1）當前銀行使用的銀行儲蓄系統(tǒng)在辦理業(yè)務時僅僅靠手

15、工操作，人工業(yè)務占據(jù)了全部，所以要求銀行業(yè)務員辦理業(yè)務時細心耐心，對數(shù)字敏感，算術(shù)水平高。它嚴重影響了工作效率，且出錯率高，儲戶辦理事務時需要等待時間過長，需要大量的銀行業(yè)務員才能滿足日益增長的存取款要求。（2）用紙張記錄保存用戶存款記錄查找繁瑣，耗時久，不方便，且容易丟失。且人工記錄不能保證萬無一失，容易出現(xiàn)數(shù)據(jù)錄入錯誤。隨著用戶數(shù)的增多，這個缺陷會越發(fā)凸顯。（3）存款記錄保密性差，任何一個業(yè)務員都可以隨意更改查閱用戶數(shù)據(jù)，用戶的資料容易泄漏，帶來安全隱患。（4）業(yè)務員服務的時間有限，不能24小時辦理業(yè)務，沒有應急處理，不能更好的解決群眾的需求。（5）所有客戶的業(yè)務都由業(yè)務員手工辦理，浪費人

16、力資源。有的簡單的業(yè)務經(jīng)改進可由機器完成，完全不用人工參與，這樣節(jié)約了人力成本，也提高效率。（6）對現(xiàn)有系統(tǒng)的改進維護只能依靠增多業(yè)務員數(shù)量，增多銀行分行數(shù)目，提高業(yè)務員業(yè)務素質(zhì)來實現(xiàn)。增多業(yè)務員數(shù)量會導致銀行人員支出大大增多，同時需要多選址建設分行，或者擴大分行規(guī)模，費用代價巨大。業(yè)務員的業(yè)務素質(zhì)需要培養(yǎng)，不能短期無限看見成效，及培養(yǎng)新人員需要一定的時間，這又浪費資金和人力資源。對現(xiàn)用系統(tǒng)的改進型維護已經(jīng)不能解決儲戶越來越多、儲戶時間越來越長的問題。第三章3.3解:數(shù)據(jù)流圖 用ER圖描繪系統(tǒng)中的數(shù)據(jù)對象。3.4 用ER圖描繪系統(tǒng)中的數(shù)據(jù)對象。數(shù)據(jù)流圖3.5（1）實體-聯(lián)系圖（2）數(shù)據(jù)流圖（3

17、）HIPO圖第五章5.3蓄系統(tǒng)不能是兩個分開的子系統(tǒng)，是相同的前臺單個處理機票預訂系統(tǒng)可以是兩個子系統(tǒng)，預定和取票是不同的處理方式（后臺批量和前臺單個）5.4解：（1）數(shù)據(jù)流圖：分解后：（2）需求說明： 1.功能需求：可以輸入調(diào)資的標準，輸入教師檔案，經(jīng)調(diào)資給出新的教師檔案，需要存儲檔案 2性能需求：軟件的響應時間應小于0.5s，更新處理要快 3靈活需求：當需求發(fā)生某些變化時，該軟件應該能夠適應這些變化 4故障處理要求：出現(xiàn)錯誤時，應給予警告或提示 （3）（a）比較耗時，因為它要檢索所有的檔案，（b）從速度上看比較快，但是（b）需要排序算法，比較復雜，（a）對于設計來講比較簡單 .（4）畫出的

18、數(shù)據(jù)流圖比較適合（A）的算法 第六章6.3解：流程圖： 盒圖： 6.7解(1)(2)6.8解：流程圖：環(huán)形復雜度：V(G)結(jié)點E弧數(shù)n1=17-11+1=7=判斷結(jié)點 1=6 17封閉的區(qū)域數(shù)邏輯有問題，當Z0時，容易形成死循環(huán)；條件Y5包含條件Y=2。第七章7.2語句覆蓋的含義是，選擇足夠多的測試數(shù)據(jù)，使被測試程序中的每個語句至少執(zhí)行一次。第九章9.1答: OO=objects+classes+inheritance+communication with messages 也就是說，面向?qū)ο缶褪羌仁褂脤ο笥质褂妙惡屠^承等機制，而且對象之間僅能通過傳遞消息實現(xiàn)彼此通信。面向?qū)ο蠓椒▽W的優(yōu)點：1

19、、與人類習慣的思維方法一致；2、穩(wěn)定性好；3、可重用性好；4、較易開發(fā)大型軟件產(chǎn)品；5、可維護性好。9.2答:把客觀世界中的實體抽象為問題域中的對象。它與傳統(tǒng)數(shù)據(jù)相同的是，它們都是現(xiàn)實實體特在在計算機中的抽象表示:不同的是，對象是進行處理的主體，而傳統(tǒng)數(shù)據(jù)是被動的接受外部指令對它進行處理；對象對實體特征進行了封裝，而傳統(tǒng)數(shù)據(jù)沒有封裝；對象比傳統(tǒng)數(shù)據(jù)更為接近自然實體。9.3類是對具有相同屬性和行為的一個或多個對象的描述。9.4廣義地說，繼承是指能夠直接獲得已有的性質(zhì)和特征，而不必重復定義它們。在面向?qū)ο蟮能浖夹g(shù)中，繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機制。9.5答:所謂模型，就是為了理

20、解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。模型是一種思考工具，利用這種工具可以把知識規(guī)范地表示出來。其中，IT=105,MTTF1=0.4,T1=160,n1=100,MTTF2=2,T2=320,n2=300。 為了開發(fā)復雜的軟件系統(tǒng)，系統(tǒng)分析員應該從不同角度抽象出目標系統(tǒng)的特性，使用精確的表示方法構(gòu)造系統(tǒng)的模型，驗證模型是否滿足用戶對目標系統(tǒng)的需求，并在設計過程中逐漸把和實現(xiàn)有關的細節(jié)加進模型中，直至最終用程序?qū)崿F(xiàn)模型。對于那些因過分復雜而不能直接理解的系統(tǒng)，特別需要建立模型，建模的目的主要是為了減少復雜性。9.6對象模型表示靜態(tài)的、結(jié)構(gòu)化的系統(tǒng)的“數(shù)據(jù)”性質(zhì)。它是對模

21、擬客觀世界實體的對象以及對象彼此間的關系的映射，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。通常使用UML提供的類圖來建立對象模型。在UML中術(shù)語“類“的實際含義是，一個類及屬于該類的對象9.7動態(tài)模型表示瞬時的、行為化的系統(tǒng)的“控制”性質(zhì)，它規(guī)定了對象模型中的對象的合法變化序列。通常，用UML 提供的狀態(tài)圖來描繪對象的狀態(tài)、觸發(fā)狀態(tài)轉(zhuǎn)換的事件以及對象的行為(對事件的響應)。每個類的動態(tài)行為用一張狀態(tài)圖來描繪，各個類的狀態(tài)圖通過共享事件合并起來，從而構(gòu)成系統(tǒng)的動態(tài)模型。也就是說，動態(tài)模型是基于事件共享而互相關聯(lián)的一組狀態(tài)圖的集合。9.8功能模型表示變化的系統(tǒng)的“功能”性質(zhì)，它指明了系統(tǒng)應該“做什么”，因此更直接地反

22、映了用戶對目標系統(tǒng)的需求。功能模型由一組數(shù)據(jù)流圖組成。在面向?qū)ο蠓椒▽W中，數(shù)據(jù)流圖遠不如在結(jié)構(gòu)分析，設計方法中那樣重要。簡單的處理(或用例)對應于更基本的對象提供的服務。有時一個處理(或用例)對應多個服務，也有一個服務對應多個處理(或用例)的時候。(1)數(shù)據(jù)流圖中的數(shù)據(jù)存儲，以及數(shù)據(jù)的源點/終點，通常是對象模型中的對象。(2)數(shù)據(jù)流圖中的數(shù)據(jù)流，往往是對象模型中對象的屬性值，也可能是整個對象。(3)用例圖中的行為者，可能是對象模型中的對象。(4)功能模型中的處理(或用例)可能產(chǎn)生動態(tài)模型中的事件。(5)對象模型描述了數(shù)據(jù)流圖中的數(shù)據(jù)流、數(shù)據(jù)存儲以及數(shù)據(jù)源點/終點的結(jié)構(gòu)。9.99.10第十章10.11、對象模型：2、動態(tài)模型：3、功能模型10.4對象模型是三個模型中最關鍵的。它的作用是描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，包括構(gòu)成系統(tǒng)的類和對象、它們的屬性和操作以及它們之間的聯(lián)系。UML中類圖適用于建立對象模型，狀態(tài)圖適用于建立動態(tài)模型。每個類的動態(tài)行為用一張狀態(tài)圖來表示，各個類的狀態(tài)圖通過事件合并起來，構(gòu)成系統(tǒng)的動態(tài)模型。也就是說，動態(tài)模型是基于事件共享而相互關聯(lián)的一組狀態(tài)圖的集合。建立對象模型大體上按照下列順序進行:尋找問題域內(nèi)的對象，識別出對