文章目錄
- 第1題
- 第2題
- 第3題
- 第4題
- 第5題
- 第6題
- 第7題
- 第8題
- 第9題
- 第10題
- 第11題
- 第12題
第1題
一、什麼是軟體危機?它有哪些典型表現?為什麼會出現軟體危機?
答:軟體危機是指在計算機軟體開發、使用與維護過程中遇到的一系列嚴重問題和難題。它包括兩方面:如何開發軟體,已滿足對軟體日益增長的需求;如何維護數量不斷增長的已有軟體。
軟體危機的典型表現:
(1) 對軟體開發成本和進度的估計常常很不準确。常常出現實際成本比估算成本高出一個數量級、實際進度比計劃進度拖延幾個月甚至幾年的現象。而為了趕進度和節約成本所采取的一些權宜之計又往往損害了軟體産品的品質。這些都降低了開發商的信譽,引起使用者不滿。
(2) 使用者對已完成的軟體不滿意的現象時有發生。
(3) 軟體産品的品質往往是靠不住的。
(4) 軟體常常是不可維護的。
(5) 軟體通常沒有适當的文檔資料。文檔資料不全或不合格,必将給軟體開發和維護工作帶來許多難以想象的困難和難以解決的問題。
(6) 軟體成本、軟體維護費在計算機系統總成本中所占比例逐年上升。
(7) 開發生産率提高的速度遠跟不上計算機應用普及的需求。
軟體危機出現的原因:
(1) 來自軟體自身的特點:是邏輯部件,缺乏可見性;規模龐大、複雜,修改、維護困難。
(2) 軟體開發與維護的方法不當:忽視需求分析;認為軟體開發等于程式編寫;輕視軟體維護。
(3) 供求沖突将是一個永恒的主題:面對日益增長的軟體需求,人們顯得力不從心。
第2題
2.假設自己是一家軟體公司的總工程師,當把圖1.1給手下的軟體工程師們觀看,告訴他們及時發現并改正錯誤的重要性時,有人不同意這個觀點,認為要求在錯誤進入軟體之前就清楚它們是不現實的,并舉例說:“如果一個故障是編碼錯誤造成的,那麼,一個人怎麼能在設計階段清除它呢?”應該怎麼反駁他?
答:在軟體開發的不同階段進行修改付出的代價是很不相同的,在早期引入變動,涉及的面較少,因而代價也比較低;在開發的中期,軟體配置的許多成分已經完成,引入一個變動要對所有已完成的配置成分都做相應的修改,不僅工作量大,而且邏輯上也更複雜,是以付出的代價劇增;在軟體“已經完成”是在引入變動,當然付出的代價更高。一個故障是代碼錯誤造成的,有時這種錯誤是不可避免的,但要修改的成本是很小的,因為這不是整體構架的錯誤。
第3題
3.什麼是軟體工程?它有哪些本質特征?怎樣用軟體工程消除軟體危機?
1993年IEEE的定義:軟體工程是:①把系統的、規範的、可度量的途徑應用于軟體開發、運作和維護過程,也就是把工程應用于軟體;②研究①中提到的途徑。
軟體工程的本質特征:
(1) 軟體工程關注于大型程式(軟體系統)的構造
(2) 軟體工程的中心課題是分解問題,控制複雜性
(3) 軟體是經常變化的,開發過程中必須考慮軟體将來可能的變化
(4) 開發軟體的效率非常重要,是以,軟體工程的一個重要課題就是,尋求開發與維護軟體的更好更有效的方法和工具
(5) 和諧地合作是開發軟體的關鍵
(6) 軟體必須有效地支援它的使用者
(7) 在軟體工程領域中是由具有一種文化背景的人替具有另一種文化背景的人完成一些工作
消除軟體危機的途徑:
(1) 對計算機軟體有一個正确的認識(軟體≠程式)
(2) 必須充分認識到軟體開發不是某種個體勞動的神秘技巧,而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目
(3) 推廣使用在實踐中總結出來的開發軟體的成功技術和方法
(4) 開發和使用更好的軟體工具
第4題
4.簡述結構化範型和面向對象範型的要點,并分析他們的優缺點。
(1)傳統方法學:也稱為生命周期方法學或結構化範型。優點:把軟體生命周期劃分成基幹個階段,每個階段的任務相對獨立,而且比較簡單,便于不同人員分工協作,進而降低了整個軟體開發過程的困難程度。缺點:當軟體規模龐大時,或者對軟體的需求是模糊的或會承受時間而變化的時候,開發出的軟體往往不成功;而且維護起來仍然很困難。
(2)面向對象方法學:優點:降低了軟體産品的複雜性;提高了軟體的可了解性;簡化了軟體的開發和維護工作;促進了軟體重用。
第5題
5.根據曆史資料可以做出如下的假設:
對計算機存儲容量的需求大緻按下面公式描述的趨勢逐年增加:
M=4080e0.28(Y-1960)
存儲器的價格按下面公式描述的趨勢逐年下降:
P1=0.3×0.72Y-1974(美分/位)
如果計算機字長為16位,則存儲器價格下降的趨勢為:
P2=0.048×0.72Y-1974(美元/字)
在上列公式中Y代表年份,M是存儲容量(字數),P1和P2代表價格。
基于上述假設可以比較計算機硬體和軟體成本的變化趨勢。要求計算:
(1) 在1985年對計算機存儲容量的需求估計是多少?如果字長為16位,這個存儲器的價格是多少?
(2) 假設在1985年一名程式員每天可開發出10條指令,程式員的平均工資是每月4000美元。如果一條指令為一個字長,計算使存儲器裝滿程式所需用的成本。
(3) 假設在1995年存儲器字長為32位,一名程式員每天可開發出30條指令,程式員的月平均工資為6000美元,重複(1)、(2)題。
答:(1)存儲容量需求M=4080e0.28(1985-1960)=4474263(字)
存儲器價格P=0.048×0.72(1985-1974)×4474263=5789美元
(2)需要工作量4474263/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美元
第6題
6.什麼是軟體過程?它與軟體工程方法學有何關系?
軟體過程是為了開發出高品質的軟體産品所需完成的一系列任務的架構,它規定了完成各項任務的工作步驟。
軟體工程方法學:通常把在軟體生命周期全過程中使用的一整套技術方法的集合稱為方法學,也稱範型。
軟體過程是軟體工程方法學的3個重要組成部分之一。
第7題
7.什麼是軟體生命周期模型?試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優缺點,說明每種模型的使用範圍。
答:軟體生命周期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構架構。
瀑布模型
優點:它提供了一個模闆,這個模闆使得分析、設計、編碼、測試和支援的方法可以在該模闆下有一個共同的指導。雖然有不少缺陷但比在軟體開發中随意的狀态要好得多。
缺點:(1) 實際的項目大部分情況難以按照該模型給出的順序進行,而且這種模型的疊代是間接的,這很容易由微小的變化而造成大的混亂。
(2) 經常情況下客戶難以表達真正的需求,而這種模型卻要求如此,這種模型是不歡迎具有二義性問題存在的。
(3) 客戶要等到開發周期的晚期才能看到程式運作的測試版本,而在這時發現大的錯誤時,可能引起客戶的驚慌,而後果也可能是災難性的。
快速原型模型
優點:使使用者能夠感受到實際的系統,使開發者能夠快速地構造出系統的架構。
缺點:産品的先天性不足,因為開發者常常需要做實作上的折中,可能采用不合适的作業系統或程式設計語言,以使原型能夠盡快工作。
增量模型
優點:(1) 人員配置設定靈活,剛開始不用投入大量人力資源,當核心産品很受歡迎時,可增加人力實作下一個增量。
(2) 當配備的人員不能在設定的期限内完成産品時,它提供了一種先推出核心産品的途徑,這樣就可以先釋出部分功能給客戶,對客戶起到鎮靜劑的作用。
缺點:(1) 至始至終開發者和客戶糾纏在一起,直到完全版本出來。
(2) 适合于軟體需求不明确、設計方案有一定風險的軟體項目。
該模型具有一定的市場。
螺旋模型
優點:對于大型系統及軟體的開發,這種模型是一個很好的方法。開發者和客戶能夠較好地對待和了解每一個演化級别上的風險。
缺點:(1) 需要相當的風險分析評估的專門技術,且成功依賴于這種技術。
(2) 很明顯一個大的沒有被發現的風險問題,将會導緻問題的發生,可能導緻演化的方法失去控制。
(3) 這種模型相對比較新,應用不廣泛,其功效需要進一步的驗證。
該模型适合于大型軟體的開發
第8題
8.為什麼說噴泉模型較好的展現了面向對象軟體開發過程無縫和疊代的特性?
答:因為使用面向對象方法學開發軟體時,各個階段都使用統一的概念和表示符号,是以,整個開發過程都是吻合一緻的,或者說是無縫連接配接的,這自然就很容易實作各個開發步驟的反複多次疊代,達到認識的逐漸深化,而噴泉模型則很好的展現了面向對象軟體開發過程疊代和無縫的特性。
第9題
9.試讨論Rational統一過程的優缺點。
答:優點:提高了團隊生産力,在疊代的開發過程、需求管理、基于組建的體系結構、可視化軟體模組化、驗證軟體品質及控制軟體變更等方面、針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模版和工具指導,并確定全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構,為開發過程提供較大的通用性。
缺點:RUP隻是一個開發過程,并沒有涵蓋軟體過程的全部内容,例如它缺少關于軟體運作和支援等方面的内容,此外,他沒有支援多項目的開發結構,這在一定程度上降低了在開發組織内大範圍實作重用的可能性。
第10題
10.Rational統一過程主要适用于何種項目?
答:大型的需求不斷變化的複雜軟體系統項目。
第11題
11.說明靈活過程的适用範圍
答:适用于商業競争環境下對小型項目提出的有限資源和有限開發時間的限制。
第12題
12.說明微軟過程的适用範圍
答:适用于商業環境下具有有限資源和有限開發時間限制的項目的軟體過程模式。