fo軟件編程思想拯救云計(jì)算軟件危機(jī)最佳方案

1、FO軟件編程思想拯救云計(jì)算軟件危機(jī)最佳方案60年代中期，大容量、高速度計(jì)算機(jī)的出現(xiàn)，使計(jì)算機(jī)的應(yīng)用范圍迅速擴(kuò)大，軟件開發(fā)急劇增長(zhǎng)。高級(jí)語言開始出現(xiàn)；操作系統(tǒng)的發(fā)展引起了計(jì)算機(jī)應(yīng)用方式的變化；大量數(shù)據(jù)處理導(dǎo)致第一代數(shù)據(jù)庫管理系統(tǒng)的誕生。軟件系統(tǒng)的規(guī)模越來越大，復(fù)雜程度越來越高，軟件可靠性問題也越來越突出。原來的個(gè)人設(shè)計(jì)、個(gè)人使用的方式不再能滿足要求，迫切需要改變軟件生產(chǎn)方式，提高軟件生產(chǎn)率，軟件危機(jī)開始爆發(fā)。1968年，北大西洋公約組織的

2、計(jì)算機(jī)科學(xué)家在聯(lián)邦德國(guó)召開國(guó)際會(huì)議，第一次討論軟件危機(jī)問題，并正式提出一個(gè)新的名詞：軟件工程。從此出現(xiàn)了一門新興的工程學(xué)科——軟件工程學(xué)，目的就是研究和克服軟件危機(jī)。軟件工程不能解決軟件危機(jī)軟件工程不能解決軟件危機(jī)剛開始的時(shí)候，軟件工程的確解決了一些問題。然而進(jìn)入上世紀(jì)80年代以后，盡管軟件工程研究與實(shí)踐取得了較大的成就，軟件技術(shù)水平有了長(zhǎng)足的進(jìn)展，但是軟件生產(chǎn)水平依然遠(yuǎn)遠(yuǎn)落后于硬件生產(chǎn)水平的發(fā)展速度。當(dāng)需求比較復(fù)雜的時(shí)候，軟件工程本身

3、也出現(xiàn)了危機(jī)。比如當(dāng)一個(gè)需求需要1億個(gè)模塊的時(shí)候，缺乏必要的文檔資料或者文檔資料不合格，將給軟件開發(fā)和維護(hù)帶來許多嚴(yán)重的困難和問題。云計(jì)算必須面對(duì)云計(jì)算必須面對(duì)“軟件危機(jī)軟件危機(jī)”軟件開發(fā)商很少提“軟件危機(jī)”的事情，架構(gòu)設(shè)計(jì)師根據(jù)用戶的需求，制定出開發(fā)方案后，軟件人員只需要按照要求編寫代碼就可以了。事實(shí)上國(guó)內(nèi)的很多軟件人員好象不知道有“軟件危機(jī)”這回事。傳統(tǒng)的軟件開發(fā)可以回避談?wù)摗败浖C(jī)”，畢竟是一個(gè)簡(jiǎn)單的系統(tǒng)，比如ERP，也只是一個(gè)

4、簡(jiǎn)單系統(tǒng)，即便出現(xiàn)軟件危機(jī)，影響也不會(huì)太大，最多是影響一個(gè)大型企業(yè)。然而開發(fā)云計(jì)算產(chǎn)品的時(shí)候，軟件危機(jī)就成了繞不過去的坎了。同樣是提供企業(yè)資源管理服務(wù)，影響的就不是一個(gè)企業(yè)，也是很多的企業(yè)，以及和這些企業(yè)相關(guān)以軟件工程為核心的傳統(tǒng)軟件開發(fā)方法，經(jīng)過幾十年的發(fā)展，已經(jīng)達(dá)到了一定的高度，而且也出現(xiàn)了大量的創(chuàng)新方法和思想。比如高級(jí)語言的出現(xiàn)，面向?qū)ο缶幊?，圖形化編程，程序驗(yàn)證，構(gòu)件技術(shù)，UML，MDA，SOA，敏捷開發(fā)等等。1、ModelDr

5、ivenArchitecture模型驅(qū)動(dòng)架構(gòu)UML是MDA所使用的關(guān)鍵技術(shù)，任何使用MDA創(chuàng)建的應(yīng)用程序都基于標(biāo)準(zhǔn)化的，與平臺(tái)無關(guān)的UML模型。這樣，就意味著應(yīng)用程序被定義為與平臺(tái)無關(guān)，所以這樣的應(yīng)用程序就是可移植的。這很容易讓人想到Java所宣稱的“writeoncerunanywhere”，試圖去構(gòu)建一個(gè)平臺(tái)無關(guān)的框架，如SwingUI庫。但是這種想法必須在性能和平臺(tái)集成上作出折衷，而在過去這種折衷是很多產(chǎn)品失敗的根源，由于這些失敗

6、，業(yè)界仍然非常懷疑MDA的宣言。2、敏捷開發(fā)AM是一種態(tài)度，而不是一個(gè)說明性的過程。AM是敏捷建模者們堅(jiān)持的價(jià)值觀、敏捷建模者們相信的原則、敏捷建模者們應(yīng)用的實(shí)踐組成的集合。AM描述了一種建模的風(fēng)格。當(dāng)它應(yīng)用于敏捷的環(huán)境中時(shí)，能夠提高開發(fā)的質(zhì)量和速度，同時(shí)能夠避免過度簡(jiǎn)化和不切實(shí)際的期望。AM是對(duì)已有方法的補(bǔ)充，而不是一個(gè)完整的方法論。AM并不是要反對(duì)文檔。文檔的創(chuàng)建和維護(hù)都會(huì)增大項(xiàng)目涉眾的投資。敏捷文檔盡可能的簡(jiǎn)單，盡可能的小，目的只

7、集中在和目前開發(fā)的系統(tǒng)有直接關(guān)系的事情上，充分了解受眾的需要。AM也不是要反對(duì)CASE工具。敏捷建模者使用那些能夠幫助開發(fā)人員提高效果，提升價(jià)值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡(jiǎn)單的工具。一直以來，國(guó)外優(yōu)秀的軟件工程師和軟件研究人員殫盡竭慮，尋找提高軟件開發(fā)效率的方法和思想。然而這些優(yōu)秀的方法仍然無法解決軟件危機(jī)難題。由此可見，如果只在傳統(tǒng)的軟件開發(fā)思想上進(jìn)行創(chuàng)新，將很難找到解決軟件危機(jī)的“銀彈”。只有在思想上發(fā)生革命性