軟件危機與軟件工程

軟件危機與軟件工程第一頁，共五十九頁。軟件危機0美元支票 一位主管收到了一張由計算機開出的0美元的賬單，在嘲笑了“愚蠢的計算機”后他將賬單丟進了垃圾桶，一個月后，又一張賬單寄來了，還標(biāo)志著30天的逾期，這樣的情形持續(xù)了4個月，最后還帶來了一封信，警告如果再不付賬的話，將會采取法律行動，由于擔(dān)心自己的信用度，這個主管在一個軟件工程師的建議下，寄出了一張0美元的支票，最后一張0美元的收據(jù)送到了，該主管小心翼翼地將這張不同尋常的收據(jù)保存起來以備將來查詢。第二頁，共五十九頁。軟件危機（續(xù)）有錯誤的愛國者導(dǎo)彈 1991年海灣戰(zhàn)爭中，一枚飛毛腿導(dǎo)彈穿過了愛國者反導(dǎo)彈的防御，擊中了沙特阿拉伯的Dhahran附件的一個兵營，造成28名美國人死亡，98人受傷。這個錯誤是由累積的定時錯誤引起的，愛國者導(dǎo)彈每次只能工作幾小時，超過這個時間后，系統(tǒng)時鐘就會復(fù)位?？杀氖切碌能浖诙觳胚\到。

第三頁，共五十九頁。軟件危機（續(xù)）美國國內(nèi)稅收處20世紀(jì)年代讓Sperry公司建立一套聯(lián)邦稅收表格自動處理系統(tǒng)，該系統(tǒng)被證明不適合當(dāng)前的工作量，花費幾乎是預(yù)算的2倍，到1996年，共花費了40億美元，但情況并沒改善。原因是“沒有充分計劃就錯誤行事”。第四頁，共五十九頁。軟件危機的表現(xiàn)超出預(yù)算時間和成本 研究表明，每8個新的大型軟件中就有2個會被取消，軟件開發(fā)時間平均超出計劃的50%，而軟件開發(fā)中的主要成本是人力資源成本，進度的落后意味著成本的增加用戶對生產(chǎn)出的軟件不滿意 開發(fā)人員往往不注重或不善于和客戶交流，找出客戶真正需要的東西，匆忙地進行開發(fā)，在開地過程中又不能從客戶那里得到反饋信息，最后生產(chǎn)出的軟件和客戶想要的相差很遠(yuǎn)，難免出現(xiàn)糾紛。第五頁，共五十九頁。軟件危機的表現(xiàn)（續(xù)）軟件有殘存的錯誤 研究表明，所有的大型系統(tǒng)中，大約有3/4的系統(tǒng)有運行問題，要么不是像預(yù)料的工作，就是根本不能使用軟件產(chǎn)品不可維護 不能改正錯誤 在原有模塊上不能增加新的功能 不能增加新的模塊第六頁，共五十九頁。軟件危機的表現(xiàn)（續(xù)）文檔資料不完整 軟件文檔是交流平臺，管理工具，必須和軟件同步更新軟件生產(chǎn)率的提高跟不上硬件的發(fā)展速度

摩爾定律：每隔18個月計算機硬件的運算速度提高一倍,價格下降一半

軟件：手工開發(fā)為主第七頁，共五十九頁。軟件危機的表現(xiàn)（續(xù)）軟件成本在計算機系統(tǒng)總成本中的比例不斷提高而軟件 維護的成本占軟件的成本也越來越高第八頁，共五十九頁。引起軟件危機的原因軟件開發(fā)無計劃性 沒有經(jīng)過仔細(xì)考慮就匆忙開發(fā),出現(xiàn)問題才想辦法補救,不能保證軟件開發(fā)進度和預(yù)算,不能保證軟件質(zhì)量，在進度落后時，盲目增加人手，結(jié)果適得其反第九頁，共五十九頁。引起軟件危機的原因（續(xù)）軟件需求不充分 沒有將問題搞清楚就匆忙上馬，在開發(fā)過程中又不能和客戶有效地溝通，許多問題在交付軟件時才集中地爆發(fā)出來，這時候已經(jīng)是大勢已去，難以挽回了（和數(shù)值計算軟件和平時學(xué)習(xí)語言編寫的程序不同，在實際的軟件開發(fā)中,首先應(yīng)該滿足的是客戶的需要，開發(fā)軟件不是為了展示個人的技巧。）第十頁，共五十九頁。引起軟件危機的原因（續(xù)）軟件開發(fā)過程無規(guī)范 開發(fā)過程沒有統(tǒng)一的方法和規(guī)范 不重視文檔 各開發(fā)人員之間的接口沒有統(tǒng)一規(guī)劃第十一頁，共五十九頁。引起軟件危機的原因（續(xù)）軟件產(chǎn)品無評測手段個人提交產(chǎn)品時沒有進行測試 模塊之間接口沒有測試 整個系統(tǒng)沒有進行整體測試 忽略壓力及性能測試

第十二頁，共五十九頁。軟件危機解決之道:軟件工程1968年北大西洋公約組織的計算機科學(xué)家在聯(lián)邦德國召開的國際學(xué)術(shù)會議上第一次提出了“軟件危機”(softwarecrisis)這個名詞。

1968年秋季，北約的科技委員會召集了近50名一流的編程人員、計算機科學(xué)家和工業(yè)界巨頭，討論和制定擺脫“軟件危機”的對策。在那次會議上第一次提出了軟件工程（softwareengineering）這個概念用工程化的理念、方法進行軟件開發(fā)第十三頁，共五十九頁。軟件工程的定義軟件工程[IEE93]將系統(tǒng)的、規(guī)范的、可度量的方法應(yīng)用于軟件的開發(fā)、運行和維護的過程；上述方法的研究第十四頁，共五十九頁。軟件工程基本原理B.W.Boehm提出7條原理，互相獨立，最小集合其他軟件工程原理在此基礎(chǔ)上組合、蘊含、派生第十五頁，共五十九頁。軟件工程基本原理-1用分階段的生命周期計劃嚴(yán)格管理不成功的軟件中有一半左右是由于計劃不同造成的應(yīng)該將軟件生命周期劃分成若干個階段，并相應(yīng)制定出切實可行的計劃，并按計劃對軟件的開發(fā)和維護進行管理六類計劃：項目概要計劃，里程碑計劃，項目控制計劃，產(chǎn)品控制計劃，驗證計劃，運行維護計劃第十六頁，共五十九頁。軟件工程基本原理-2堅持進行階段評審統(tǒng)計表明，大部分錯誤是在編碼之前造成的錯誤發(fā)現(xiàn)與改正越晚，所需付出的代價也越高（見下頁）堅持階段評審，可以避免錯誤的“水波效應(yīng)”第十七頁，共五十九頁。各階段改正錯誤的相對花費第十八頁，共五十九頁。軟件工程基本原理-3實行嚴(yán)格的產(chǎn)品控制盡量避免修改需求修改需求必須在嚴(yán)格的管理下進行----配置管理第十九頁，共五十九頁。第二十頁，共五十九頁。軟件工程基本原理-4采用現(xiàn)代程序設(shè)計技術(shù)結(jié)構(gòu)化程序設(shè)計技術(shù)—自頂向下，逐步求精面向?qū)ο笤O(shè)計技術(shù)—思想而非僅為技術(shù)第二十一頁，共五十九頁。軟件工程基本原理-5結(jié)果應(yīng)能清楚地審查度量是管理的基礎(chǔ)形成自己的管理數(shù)據(jù)資料庫，盡量精確地對系統(tǒng)進行計劃、測量、修正第二十二頁，共五十九頁。軟件工程基本原理-6開發(fā)小組人員應(yīng)少而精IBM的紐約時報項目（1971）：22個月內(nèi)寫了83000行程序，在1年的運行過程中只找出了25個錯誤，主要的程序員平均每年編寫1個錯誤和10000行代碼成功原因：該項目是IBM的樣本項目每個程序員都是尖子中的尖子技術(shù)支持極為強大，編譯器作者隨叫隨到項目領(lǐng)導(dǎo)F.TerryBaker是一個極好的管理者和領(lǐng)導(dǎo)者，“天才程序員”第二十三頁，共五十九頁。軟件工程基本原理-6（續(xù)）一個好的程序員的效率是普通程序員的4-5倍開發(fā)小組人員增多，由于交流討論問題所造成的通信開銷急劇增加（特別是程序員使用其他程序員所開發(fā)的模塊）第二十四頁，共五十九頁。軟件工程基本原理-7不斷改進軟件工程實踐發(fā)展和采用新技術(shù)收集相關(guān)數(shù)據(jù)第二十五頁，共五十九頁。軟件生產(chǎn)中的問題：

----本質(zhì)的和偶發(fā)的硬件限制光傳播速度制造工藝:電子能通過的最窄的寬度為3個原子的直徑

軟件:沒有銀彈第二十六頁，共五十九頁。軟件開發(fā)中的困難困難:本質(zhì)的（固有的）和偶發(fā)的（非固有的）

軟件的本質(zhì)困難（每一種的原因及后果）復(fù)雜性一致性可變性不可見性第二十七頁，共五十九頁。軟件開發(fā)中的困難:復(fù)雜性(1)原因:1.如果程序占N個字，則可能的狀態(tài)有216*N種:非線性增長產(chǎn)品的不同塊之間是要相互影響（如全局變量）第二十八頁，共五十九頁。軟件開發(fā)中的困難:復(fù)雜性(2)后果:軟件產(chǎn)品很難理解,開發(fā)小組成員間不能進行良好的溝通,造成開發(fā)超時和超支，并且造成說明文檔中出現(xiàn)的錯誤、影響對軟件過程的管理

維護過程變得很復(fù)雜，除非維護人員對產(chǎn)品真正理解第二十九頁，共五十九頁。軟件開發(fā)中的困難:復(fù)雜性(3)對策:結(jié)構(gòu)化方法:自頂向下,逐步求精面向?qū)ο蠓椒?封裝、消息驅(qū)動、繼承、復(fù)用能夠減少復(fù)雜性，從而提高可維護性，但并不能將軟件復(fù)雜性完全消除第三十頁，共五十九頁。軟件開發(fā)中的困難:一致性(1)設(shè)計軟件時與現(xiàn)有系統(tǒng)的接口一致性在設(shè)計新系統(tǒng)時，軟件設(shè)計師與其它設(shè)備的設(shè)計師之間的一致性第三十一頁，共五十九頁。軟件開發(fā)中的困難:一致性(2)原因：普遍存在的誤解：軟件是系統(tǒng)中一種最容易與別的設(shè)備進行接口的成分后果：軟件獲得了一種不必要的復(fù)雜性，而這種復(fù)雜性不是由軟件自身的結(jié)構(gòu)引起的第三十二頁，共五十九頁。軟件開發(fā)中的困難:可變性(1)軟件需要改變的原因:1.軟件是現(xiàn)實世界的模擬,軟件要隨著現(xiàn)實世界的改變而改變用戶對軟件功能的擴展要求,超越原來的設(shè)計軟件改變的最有吸引力的地方是軟件比硬件更容易改變成功的軟件能夠超越支持其運行的硬件的生存期,在更換硬件后繼續(xù)使用第三十三頁，共五十九頁。軟件開發(fā)中的困難:可變性(2)后果:從長遠(yuǎn)來看,對產(chǎn)品進行大面積的維護是不明智的,從頭開始對軟件重新編碼有進成本更低,但人們對軟件本質(zhì)的忽視而常常要求對軟件進行在的改動第三十四頁，共五十九頁。軟件開發(fā)中的困難:不可見性(1)原因(難以將代碼與實際的軟件對應(yīng)起來):目前不存在一種普遍接受的方法來對一個完整的軟件產(chǎn)品進行描述，或者對產(chǎn)品做出某種概述，現(xiàn)有的各種說明工具（如UML、數(shù)據(jù)流圖、程序結(jié)構(gòu)圖)極少有平面的，更別說是分層的，圖表中有太多的交叉，難以一下子給出軟件的全貌第三十五頁，共五十九頁。軟件開發(fā)中的困難:不可見性(2)后果:1.沒有一種圖表能將軟件的各個方面都體現(xiàn)出來，并且也沒有一種方法能夠確定在使用一種形象化描述方法對產(chǎn)品進行描述時，我們遺漏了哪些2.不能對軟件進行形象化描述不僅使軟件難于理解，而且極大地阻礙了軟件專家之間的溝通第三十六頁，共五十九頁。沒有銀彈(1)對于軟件的本質(zhì)問題，我們無法解決，無法找到一種在生產(chǎn)上快速取得大數(shù)量級提高的方法，即銀彈第三十七頁，共五十九頁。沒有銀彈(2)對于軟件的偶發(fā)問題是可以解決的

Brooks認(rèn)為生產(chǎn)軟件的最困難的部分在需求階段、規(guī)格說明和設(shè)計階段，而不是實現(xiàn)階段,建議我們改變軟件的生產(chǎn)方式：在任何可能的情況下購買已經(jīng)開發(fā)好的軟件，而不是定制開發(fā)使用快速原型和增量式建造技術(shù)培養(yǎng)偉大的設(shè)計者第三十八頁，共五十九頁。改進軟件過程(1)“軟件開發(fā)的根本問題在于人們不能對軟件過程進行管理”美國國防部在位于匹茲堡的卡耐基.梅隆大學(xué)成立了軟件工程研究所（softwareengineeringInstitute,SEI）SEI的一個最主要的成功是建立了能力成熟度模型（CapabilityMaturityModel,CMM）國際標(biāo)準(zhǔn)化組織（ISO）也制定了相應(yīng)的ISO-9000系列標(biāo)準(zhǔn)、ISO/IEC15504等

第三十九頁，共五十九頁。改進軟件過程(2)

能力成熟度模型CMM是一組用于改進軟件過程的相關(guān)策略，它與實際使用的軟件生命周期模型沒有關(guān)系（成熟度是對軟件過程本身的度量），CMM模型包括：

1.用于軟件的SW—CMM2.用于人力資源管理的P—CMM3.用于系統(tǒng)工程的SE—CMM4.用于集成產(chǎn)品開發(fā)的IPD—CMM5.用于軟件收集的SA—CMM

為避免不一致和冗余，1997年將前4個模型統(tǒng)一為CMMI

第四十頁，共五十九頁。改進軟件過程(3)軟件過程不僅包括軟件生產(chǎn)的各種技術(shù)和工具，也包括技術(shù)方面和管理方面的內(nèi)容

SW—CMM是基于以下觀點的：新技術(shù)本身并不能導(dǎo)致產(chǎn)量和利潤的增加，我們的問題主要出現(xiàn)在軟件過程管理上

SW—CMM模型的策略是改進軟件過程的管理，相信技術(shù)的提高是一個自然的結(jié)果，軟件過程做為一個整體所獲得的改進將導(dǎo)致較高質(zhì)量的軟件的產(chǎn)生，并且將會有較少項目超時或超支

第四十一頁，共五十九頁。CMM軟件過程改進不可能在一夜之間實現(xiàn),SW-CMM模型對過程的改變是逐步的,該模型定義了5個成熟度級別,一個軟件組織通過每一步的細(xì)微演變,將自己的成熟度級別提高到更高一級上第四十二頁，共五十九頁。成熟度級別1(初始級)有效的軟件過程管理方法在本質(zhì)上沒有獲得使用,軟件開發(fā)成功與否依賴于當(dāng)前的軟件開發(fā)人員整個開發(fā)過程沒有計劃,不可預(yù)測,軟件開發(fā)經(jīng)常超時和超支許多措施都是在軟件開發(fā)遇到困難進采取的，而不是事先計劃好的（在這樣的組織里，“高技術(shù)”只能引起更大的混亂）

第四十三頁，共五十九頁。成熟度級別2（可重復(fù)級）

使用了基本的軟件項目管理措施1.根據(jù)從類似產(chǎn)品中獲得的經(jīng)驗對新的產(chǎn)品進行計劃和管理2.使用了基本的測量技術(shù)(包括對花費和工作進度表的仔細(xì)跟蹤)3.項目中的測量為以后項目時間和費用表的制定提供現(xiàn)實的依據(jù)4.通過測量,管理人員能夠及時發(fā)現(xiàn)問題，并立刻采取措施阻止這些問題演化成大的危機第四十四頁，共五十九頁。成熟度級別3（已定義級）軟件開發(fā)過程的完全文檔化1.軟件開發(fā)過程在所有的管理的技術(shù)方面都有明確的定義2.在任何可能的地方不斷努力改進軟件開發(fā)過程3.以評審方式來保證軟件質(zhì)量4.引進CASE技術(shù)來進一步提高軟件質(zhì)量的軟件生產(chǎn)力

第四十五頁，共五十九頁。成熟度級別4（已管理級）為每個項目設(shè)計了質(zhì)量目標(biāo)和生產(chǎn)目標(biāo)1.在軟件開發(fā)過程中對這兩項指標(biāo)不斷進行測量，當(dāng)與目標(biāo)有不可接受的偏離時，則能夠糾正措施對其進行糾正2.設(shè)立統(tǒng)計質(zhì)量控制（如每千行代碼的錯誤數(shù)），確保管理者能夠區(qū)別質(zhì)量和生產(chǎn)標(biāo)準(zhǔn)的隨機偏離及有意的違背

第四十六頁，共五十九頁。成熟度級別5（優(yōu)化級）

持續(xù)改進軟件過程

1.人們用靜態(tài)質(zhì)量和過程控制技術(shù)對軟件組織進行指引，在每個項目中獲取的知識在以后的項目中可得到利用2.開發(fā)過程形成了一個回饋性的良性循環(huán)，從而使軟件生產(chǎn)和軟件質(zhì)量獲得不斷提高

第四十七頁，共五十九頁。CMM總結(jié)(1)軟件組織改進自己的軟件過程,需要:1.努力對組織當(dāng)前的軟件過程有一個理解2.對想要獲得的軟件過程進行明確的闡述

3.確定為實現(xiàn)過程提高要采取的措施，并確定措施實現(xiàn)的先后順序4.制定一個實現(xiàn)過程提高的計劃并實施該計劃

第四十八頁，共五十九頁。CMM總結(jié)(2)第四十九頁，共五十九頁。CMM總結(jié):KPA(1)關(guān)鍵過程區(qū)(KPA):組織在努力實現(xiàn)下一個級別進要努力實現(xiàn)的目標(biāo)成熟度級別2的KPA:

1.配置控制2.軟件質(zhì)量保證3.項目計劃4.項目追蹤5.需求管理第五十頁，共五十九頁。CMM總結(jié):KPA(2)級別5的KPA

1.錯誤預(yù)防2.技術(shù)更新3.過程變化管理級別2與級別5的KPA比較

級別2:錯誤發(fā)現(xiàn)與糾正級別5:錯誤預(yù)防

第五十一頁，共五十九頁。CMM提升經(jīng)驗(1)花費時間:從級別1到級別2:3到5年從級別2到級別3:1.5年到3年

SEI開發(fā)出一系列的調(diào)查表,做為評估的基礎(chǔ),評估的目的是指出軟件組織當(dāng)前軟件過程中的不足,并且指明軟件組織改進其過程應(yīng)采用的方法第五十二頁，共五十九頁。CMM提升經(jīng)驗(2)最初目標(biāo):美國國防部生產(chǎn)軟件的合同商的軟件過程進行評估,到1998年為止,任何想與空軍簽訂合同的軟件商必須達(dá)到CMM3級以上第五十三頁，共五十九頁。軟件過程改進的其他努力(1)ISO9000,ISO90011.

ISO9000的原則是:與該標(biāo)準(zhǔn)保持一致并不能保證生產(chǎn)出高質(zhì)量的產(chǎn)品,但這樣可以減少生產(chǎn)出質(zhì)量低劣的產(chǎn)品的可能2.和CMM有部分重疊,但并不完全相同3.不是過程改進,而強調(diào)使用文字和圖片對整個過程進行記錄以確保整個過程的一致性和可理解性,重量在測量方法和節(jié)奏4.與歐洲公司簽定合同必通過ISO9000認(rèn)證,越來越多的美國公司也要求該認(rèn)證,如通用公司第五十四頁，共五十九頁。軟件過程改進的其他努力