【正文】 第一章一、什么是軟件危機(jī)？它有哪些典型表現(xiàn)？為什么會(huì)出現(xiàn)軟件危機(jī)？軟件危機(jī)是指在計(jì)算機(jī)軟件開發(fā)、使用與維護(hù)過程中遇到的一系列嚴(yán)重問題和難題。它包括兩方面：如何開發(fā)軟件，已滿足對軟件日益增長的需求；如何維護(hù)數(shù)量不斷增長的已有軟件。軟件危機(jī)的典型表現(xiàn)：(1) 對軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確。常常出現(xiàn)實(shí)際成本比估算成本高出一個(gè)數(shù)量級、實(shí)際進(jìn)度比計(jì)劃進(jìn)度拖延幾個(gè)月甚至幾年的現(xiàn)象。而為了趕進(jìn)度和節(jié)約成本所采取的一些權(quán)宜之計(jì)又往往損害了軟件產(chǎn)品的質(zhì)量。這些都降低了開發(fā)商的信譽(yù)，引起用戶不滿。(2) 用戶對已完成的軟件不滿意的現(xiàn)象時(shí)有發(fā)生。(3) 軟件產(chǎn)品的質(zhì)量往往是靠不住的。 (4) 軟件常常是不可維護(hù)的。(5) 軟件通常沒有適當(dāng)?shù)奈臋n資料。文檔資料不全或不合格，必將給軟件開發(fā)和維護(hù)工作帶來許多難以想象的困難和難以解決的問題。(6) 軟件成本、軟件維護(hù)費(fèi)在計(jì)算機(jī)系統(tǒng)總成本中所占比例逐年上升。(7) 開發(fā)生產(chǎn)率提高的速度遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用普及的需求。軟件危機(jī)出現(xiàn)的原因：(1) 來自軟件自身的特點(diǎn)：是邏輯部件，缺乏可見性；規(guī)模龐大、復(fù)雜，修改、維護(hù)困難。(2) 軟件開發(fā)與維護(hù)的方法不當(dāng)：忽視需求分析；認(rèn)為軟件開發(fā)等于程序編寫；輕視軟件維護(hù)。(3) 供求矛盾將是一個(gè)永恒的主題：面對日益增長的軟件需求，人們顯得力不從心。二、假設(shè)自己是一家軟件公司的總工程師，告訴他們及時(shí)發(fā)現(xiàn)并改正錯(cuò)誤的重要性時(shí)，有人不同意這個(gè)觀點(diǎn)，認(rèn)為要求在錯(cuò)誤進(jìn)入軟件之前就清除它們是不現(xiàn)實(shí)的，并舉例說：“如果一個(gè)故障是編碼錯(cuò)誤造成的，那么，一個(gè)人怎么能在設(shè)計(jì)階段清除它呢？”應(yīng)該怎么反駁他？答：在軟件開發(fā)的不同階段進(jìn)行修改付出的代價(jià)是很不相同的，在早期引入變動(dòng)，涉及的面較少，因而代價(jià)也比較低；在開發(fā)的中期，軟件配置的許多成分已經(jīng)完成，引入一個(gè)變動(dòng)要對所有已完成的配置成分都做相應(yīng)的修改，不僅工作量大，而且邏輯上也更復(fù)雜，因此付出的代價(jià)劇增；在軟件“已經(jīng)完成”時(shí)再引入變動(dòng)，當(dāng)然付出的代價(jià)更高。一個(gè)故障是代碼錯(cuò)誤造成的，有時(shí)這種錯(cuò)誤是不可避免的，但要修改的成本是很小的，因?yàn)檫@不是整體構(gòu)架的錯(cuò)誤。三、什么是軟件工程？它有哪些本質(zhì)特征？怎樣用軟件工程消除軟件危機(jī)？1993年IEEE的定義：軟件工程是：① 把系統(tǒng)的、規(guī)范的、可度量的途徑應(yīng)用于軟件開發(fā)、運(yùn)行和維護(hù)過程，也就是把工程應(yīng)用于軟件；② 研究①中提到的途徑。軟件工程的本質(zhì)特征：(1) 軟件工程關(guān)注于大型程序(軟件系統(tǒng))的構(gòu)造(2) 軟件工程的中心課題是分解問題，控制復(fù)雜性(3) 軟件是經(jīng)常變化的，開發(fā)過程中必須考慮軟件將來可能的變化(4) 開發(fā)軟件的效率非常重要，因此，軟件工程的一個(gè)重要課題就是，尋求開發(fā)與維護(hù)軟件的更好更有效的方法和工具(5) 和諧地合作是開發(fā)軟件的關(guān)鍵(6) 軟件必須有效地支持它的用戶(7) 在軟件工程領(lǐng)域中是由具有一種文化背景的人替具有另一種文化背景的人(完成一些工作)消除軟件危機(jī)的途徑：(1) 對計(jì)算機(jī)軟件有一個(gè)正確的認(rèn)識(shí)(軟件≠程序）(2) 必須充分認(rèn)識(shí)到軟件開發(fā)不是某種個(gè)體勞動(dòng)的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項(xiàng)目(3) 推廣使用在實(shí)踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法(4) 開發(fā)和使用更好的軟件工具四、簡述結(jié)構(gòu)化范型和面向?qū)ο蠓缎偷囊c(diǎn)，并分析他們的優(yōu)缺點(diǎn)。1.傳統(tǒng)方法學(xué)：也稱為生命周期方法學(xué)或結(jié)構(gòu)化范型。優(yōu)點(diǎn)：把軟件生命周期劃分成基干個(gè)階段，每個(gè)階段的任務(wù)相對獨(dú)立，而且比較簡單，便于不同人員分工協(xié)作，從而降低了整個(gè)軟件開發(fā)過程的困難程度。缺點(diǎn)：當(dāng)軟件規(guī)模龐大時(shí)，或者對軟件的需求是模糊的或會(huì)承受時(shí)間而變化的時(shí)候，開發(fā)出的軟件往往不成功；而且維護(hù)起來仍然很困難。2.面向?qū)ο蠓椒▽W(xué)：優(yōu)點(diǎn)：降低了軟件產(chǎn)品的復(fù)雜性；提高了軟件的可理解性；簡化了軟件的開發(fā)和維護(hù)工作；促進(jìn)了軟件重用。五、15 根據(jù)歷史數(shù)據(jù)可以做出如下的假設(shè) ：對計(jì)算機(jī)存儲(chǔ)容量的需求大致按下面公式描述的趨勢逐年增加：M=(Y1960) 存儲(chǔ)器的價(jià)格按下面公式描述的趨勢逐年下降：P1=(美分/位)如果計(jì)算機(jī)字長為16位，則存儲(chǔ)器價(jià)格下降的趨勢為：P2=(美元/字)在上列公式中Y代表年份，M是存儲(chǔ)容量(字?jǐn)?shù))，P1和P2代表價(jià)格?；谏鲜黾僭O(shè)可以比較計(jì)算機(jī)硬件和軟件成本的變化趨勢。要求計(jì)算：(1) 在1985年對計(jì)算機(jī)存儲(chǔ)容量的需求估計(jì)是多少?如果字長為16位，這個(gè)存儲(chǔ)器的價(jià)格是多少?存儲(chǔ)容量需求M=（19851960）=4474263（字）存儲(chǔ)器價(jià)格P=*（19851974）*4474263=5789美元(2) 假設(shè)在1985年一名程序員每天可開發(fā)出10條指令，程序員的平均工資是每月4000美元。如果一條指令為一個(gè)字長，計(jì)算使存儲(chǔ)器裝滿程序所需用的成本。需要工作量4474263/200=22371（人/月）指令成本22371*4000=89484000美元(3) 假設(shè)在1995年存儲(chǔ)器字長為32位，一名程序員每天可開發(fā)出30條指令，程序員的月平均工資為6000美元，重復(fù)(1)、(2)題。需求估計(jì)M=（19951960）=73577679字*32*（19951974）*73577679=7127美元工作量73577679/600=122629(人/月）成本122629*6000=735776790美元六、什么是軟件過程?它與軟件工程方法學(xué)有何關(guān)系?軟件過程是為了開發(fā)出高質(zhì)量的軟件產(chǎn)品所需完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。軟件工程方法學(xué)：通常把在軟件生命周期全過程中使用的一整套技術(shù)方法的集合稱為方法學(xué)，也稱范型。軟件過程是軟件工程方法學(xué)的3個(gè)重要組成部分(方法、工具和過程)之一。七、什么是軟件生命周期模型？試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優(yōu)缺點(diǎn)，說明每種模型的使用范圍。軟件生命周期模型是跨越整個(gè)生存期的系統(tǒng)開發(fā)、運(yùn)作和維護(hù)所實(shí)施的全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。瀑布模型 優(yōu)點(diǎn)：它提供了一個(gè)模板，這個(gè)模板使得分析、設(shè)計(jì)、編碼、測試和支持的方法可以在該模板下有一個(gè)共同的指導(dǎo)。雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好得多。缺點(diǎn)：(1) 實(shí)際的項(xiàng)目大部分情況難以按照該模型給出的順序進(jìn)行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。(2) 經(jīng)常情況下客戶難以表達(dá)真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。(3) 客戶要等到開發(fā)周期的晚期才能看到程序運(yùn)行的測試版本，而在這時(shí)發(fā)現(xiàn)大的錯(cuò)誤時(shí)，可能引起客戶的驚慌，而后果也可能是災(zāi)難性的?？焖僭湍Ｐ蛢?yōu)點(diǎn)：使用戶能夠感受到實(shí)際的系統(tǒng)，使開發(fā)者能夠快速地構(gòu)造出系統(tǒng)的框架。缺點(diǎn)：產(chǎn)品的先天性不足，因?yàn)殚_發(fā)者常常需要做實(shí)現(xiàn)上的折中，可能采用不合適的操作系統(tǒng)或程序設(shè)計(jì)語言，以使原型能夠盡快工作。 增量模型優(yōu)點(diǎn)：(1) 人員分配靈活，剛開始不用投入大量人力資源，當(dāng)核心產(chǎn)品很受歡迎時(shí)，可增加人力實(shí)現(xiàn)下一個(gè)增量。(2) 當(dāng)配備的人員不能在設(shè)定的期限內(nèi)完成產(chǎn)品時(shí)，它提供了一種先推出核心產(chǎn)品的途徑，這樣就可以先發(fā)布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用。缺點(diǎn)：(1) 至始至終開發(fā)者和客戶糾纏在一起，直到完全版本出來。(2) 適合于軟件需求不明確、設(shè)計(jì)方案有一定風(fēng)險(xiǎn)的軟件項(xiàng)目。該模型具有一定的市場。螺旋模型優(yōu)點(diǎn)：對于大型系統(tǒng)及軟件的開發(fā)，這種模型是一個(gè)很好的方法。開發(fā)者和客戶能夠較好地對待和理解每一個(gè)演化級別上的風(fēng)險(xiǎn)。缺點(diǎn)：(1) 需要相當(dāng)?shù)娘L(fēng)險(xiǎn)分析評估的專門技術(shù)，且成功依賴于這種技術(shù)。(2) 很明顯一個(gè)大的沒有被發(fā)現(xiàn)的風(fēng)險(xiǎn)問題，將會(huì)導(dǎo)致問題的發(fā)生，可能導(dǎo)致演化 的方法失去控制。(3) 這種模型相對比較新，應(yīng)用不廣泛，其功效需要進(jìn)一步的驗(yàn)證。該模型適合于大型軟件的開發(fā)八、為什么說噴泉模型較好的體現(xiàn)了面向?qū)ο筌浖_發(fā)過程無縫和迭代的特性？因?yàn)槭褂妹嫦驅(qū)ο蠓椒▽W(xué)開發(fā)軟件時(shí)，各個(gè)階段都使用統(tǒng)一的概念和表示符號(hào)，因此，整個(gè)開發(fā)過程都是吻合一致的，或者說是無縫連接的，這自然就很容易實(shí)現(xiàn)各個(gè)開發(fā)步驟的反復(fù)多次迭代，達(dá)到認(rèn)識(shí)的逐步深化，而噴泉模型則很好的體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。九、試討論Rational統(tǒng)一過程的優(yōu)缺點(diǎn)。優(yōu)點(diǎn):提高了團(tuán)隊(duì)生產(chǎn)力，在迭代的開發(fā)過程、需求管理、基于組建的體系結(jié)構(gòu)、可視化軟件建模、驗(yàn)證軟件質(zhì)量及控制軟件變更等方面、針對所有關(guān)鍵的開發(fā)活動(dòng)為每個(gè)開發(fā)成員提供了必要的準(zhǔn)則、模版和工具指導(dǎo)，并確保全體成員共享相同的知識(shí)基礎(chǔ)。它建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。缺點(diǎn)：RUP只是一個(gè)開發(fā)過程，并沒有涵蓋軟件過程的全部內(nèi)容，例如它缺少關(guān)于軟件運(yùn)行和支持等方面的內(nèi)容，此外，他沒有支持多項(xiàng)目的開發(fā)結(jié)構(gòu)，這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實(shí)現(xiàn)重用的可能性。十．Rational統(tǒng)一過程主要適用于何種項(xiàng)目？大型的需求不斷變化的復(fù)雜軟件系統(tǒng)項(xiàng)目適用于商業(yè)競爭環(huán)境下對小型項(xiàng)目提出的有限資源和有限開發(fā)時(shí)間的約束適用于商業(yè)環(huán)境下具有有限資源和有限開發(fā)時(shí)間約束的項(xiàng)目的軟件過程模式第二章?應(yīng)該從哪些方面研究目標(biāo)系統(tǒng)的可行性？答：（1）開發(fā)一個(gè)軟件時(shí)，需要判斷原定的系統(tǒng)模型和目標(biāo)是否現(xiàn)實(shí)，系統(tǒng)完成后所能帶來的效益是否大到值得投資開發(fā)這個(gè)系統(tǒng)的程度，如果做不到這些，那么花費(fèi)在這些工程上的任何時(shí)間、人力、軟硬件資源和經(jīng)費(fèi)，都是無謂的浪費(fèi)?？尚行匝芯康膶?shí)質(zhì)是要進(jìn)行一次大大壓縮簡化了的系統(tǒng)分析和設(shè)計(jì)過程，就是在較高層次上以較抽象的方式進(jìn)行的系統(tǒng)分析和設(shè)計(jì)的過程?？尚行匝芯康哪康木褪怯米钚〉拇鷥r(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決。（2）一般說來，至少應(yīng)該從以下三個(gè)方面研究每種解法的可行性：。對要開發(fā)項(xiàng)目的功能、 性能和限制條件進(jìn)行分析， 確定在現(xiàn)有的資源條件下，技術(shù)風(fēng)險(xiǎn)有多大，項(xiàng)目是否能實(shí)現(xiàn)，這些即為技術(shù)可行性研究的內(nèi)容。這里的資源包括已有的或可以搞到的硬件、軟件資源，現(xiàn)有技術(shù)人員的技術(shù)水平和已有的工作基礎(chǔ)。進(jìn)行開發(fā)成本的估算以及了解取得效益的評估， 確定要開發(fā)的項(xiàng)目是否值得投資開發(fā)，這些即為經(jīng)濟(jì)可行性研究的內(nèi)容對于大多數(shù)系統(tǒng)，一般衡量經(jīng)濟(jì)上是否合算，應(yīng)考慮一個(gè)“底線”，經(jīng)濟(jì)可行性研究范圍較廣，包括成本—效益分析， 長期公司經(jīng)營策略， 開發(fā)所需的成本和資源，潛在的市場前景。有時(shí)還要研究社會(huì)可行性問題，研究要開發(fā)的項(xiàng)目是否存在任何侵犯、妨礙等責(zé)任問題。社會(huì)可行性所涉及的范圍也比較廣，它包括合同、責(zé)任、 侵權(quán)和其他一些技術(shù)人員常常不了解的陷阱等。必要時(shí)還應(yīng)該從法律、社會(huì)效益等更廣泛的方面研究每種解法的可行性。，某銀行擬開發(fā)計(jì)算機(jī)儲(chǔ)蓄系統(tǒng)。儲(chǔ)戶填寫的存款單或取款單由業(yè)務(wù)員鍵入系統(tǒng)，如果是存款，系統(tǒng)記錄存款人姓名、住址、存款類型、存款日期、利率等信息，并印出存款單給儲(chǔ)戶；如果是取款，系統(tǒng)計(jì)算利息并印出利息清單給儲(chǔ)戶。 請寫出問題定義并分析此系統(tǒng)的可行性。數(shù)據(jù)流程圖：取票圖：航空訂票系統(tǒng)技術(shù)在目前是一個(gè)技術(shù)上成熟的系統(tǒng)，并且在航空公司內(nèi)部準(zhǔn)備采取有力措施保證資金和人員配置等。因此，分階段開發(fā)“航空訂票系統(tǒng)”的構(gòu)想是可行的。為了使航空公司適應(yīng)現(xiàn)代化市場競爭的需求，促進(jìn)機(jī)票預(yù)訂管理信息化，不斷滿足旅客預(yù)訂機(jī)票的要求，爭取更好的經(jīng)濟(jì)效益，可立即著手系統(tǒng)的開發(fā)與完善。 為方便旅客，某航空公司擬開發(fā)一個(gè)機(jī)票預(yù)定系統(tǒng)。旅行社把預(yù)定機(jī)票的旅客信息（姓名、性別、工作單位、身份證號(hào)碼、旅行時(shí)間、旅行目的地等）輸入進(jìn)入該系統(tǒng)，系統(tǒng)為旅客安排航班，印出取票通知和賬單，旅客在飛機(jī)起飛的前一天憑取票通知和賬單交款取票，系統(tǒng)校對無誤即印出機(jī)票給旅客。 寫出問題定義并分析系統(tǒng)的可行性。 1 目標(biāo)：在一個(gè)月內(nèi)建立一個(gè)高效率，無差錯(cuò)的航空公司機(jī)票預(yù)定系統(tǒng) 2 存在的主要問題：人工不易管理，手續(xù)繁瑣 3 建立新系統(tǒng) ① 經(jīng)濟(jì)可行性 成本效益分析 成本估算：打印機(jī)一臺(tái)（2000元）+開發(fā)費(fèi)（3500元）=5500元 可承擔(dān) 效益估算:該系統(tǒng)有很好的社會(huì)效益，提高了航空公司售票效率，方便了旅客，售票方便化，科學(xué)化 ② 技術(shù)可行性 經(jīng)過調(diào)查分析，得到目前航空公司機(jī)票預(yù)定系統(tǒng)流程圖如下： 客戶開購票證明購票證明開購票發(fā)票發(fā)票收費(fèi)機(jī)票單機(jī)票客戶系統(tǒng)管理員系統(tǒng)管理員系統(tǒng)管理員系統(tǒng)管理員航班信息的更新查詢請求表達(dá)申請機(jī)票核對事物數(shù)據(jù)庫產(chǎn)生報(bào)表產(chǎn)生報(bào)表產(chǎn)生報(bào)表產(chǎn)生報(bào)表及賬單服務(wù)終端顯示數(shù)據(jù)客戶終端顯示數(shù)據(jù)客戶終端顯示數(shù)據(jù)在客戶端打印數(shù)據(jù)和賬單4. 目前住院病人主要由護(hù)士護(hù)理，這樣做不僅需要大量護(hù)士，而且由于不能隨時(shí)觀察危重病人的病情變化，還可能會(huì)延誤搶救時(shí)機(jī)。某醫(yī)院打算開發(fā)一個(gè)以計(jì)算機(jī)為中心的患者監(jiān)護(hù)系統(tǒng)，試寫出問題定義，并且分析開發(fā)這個(gè)系統(tǒng)的可行性可行性分析原系統(tǒng)分析：護(hù)士檢查病患救治結(jié)束需要救治開始可行性分析邏輯圖：開始醫(yī)生輸出病患標(biāo)準(zhǔn)數(shù)據(jù)服務(wù)器采集病人生理數(shù)據(jù)對比大小警報(bào)結(jié)束在預(yù)測范圍內(nèi)不在預(yù)測范圍內(nèi)醫(yī)生病人端客戶機(jī)D1：標(biāo)準(zhǔn)數(shù)據(jù)服務(wù)器D2：實(shí)測數(shù)據(jù)D3：警報(bào)數(shù)據(jù)護(hù)士D4：指定打印數(shù)據(jù)技術(shù)可行性。 雖然生理數(shù)據(jù)的采集需要涉及大量的專業(yè)精密儀器，軟件工程師并不精