軟體工程未來發展趨勢

軟體工程未來發展趨勢

 

本文的意圖是討論軟體工程的未來發展趨勢，但是軟體工程的發展不可能是孤立的，所以我們首先需要思考一下計算模型和軟體開發本身的變化和趨勢，再由此推測軟體工程的發展趨勢。

       從計算模型而言，應該來講，傳統的馮.諾依曼仍然被沿用；但從計算能力上來將，我們注意到了三個變化：

      ●CPU的運算能力按摩爾定律快速提升；但提升單顆CPU的計算能力已經越來越困難；

      ●並行運算技術以及多核多線程技術使伺服器的處理能力飛速提升；伺服器的處理能力不再是瓶頸，從而造成計算能力大量向伺服器端遷移，C/S結構被無情拋棄，薄用戶端（B/S結構）成為大勢所趨；

       ●互連網的快速普及使得雲端運算成為可能，通過互連網相連的伺服器叢集在伺服器端提供了更強大的計算能力；

      基於上述計算能力的變化，從軟體開發模式而言，我們注意到以下六個相關的趨勢：

     ●由於計算能力向伺服器端的快速集中，提供高並行計算能力和可用性的中介軟體技術被廣泛採用，甚至已經成為構建大型軟體系統的必選項；

      ● 因為採用了中介軟體技術，軟體Team Dev可以更集中關注於商務邏輯，而可以將許多細節交給中介軟體來管理，從而大大減少了需要編寫的程式碼數，也直接導致了軟體Team Dev的規模變得越來越小，但角色變得越來越專業化（如瞭解行業的需求分析員，瞭解中介軟體技術和領域構架的架構師等）；

       ●計算能力的增強，使軟體越來越易用，從而使軟體變得無處不在，需要的軟體開發人員數量急劇增長(組織形態是大量的小規模Team Dev)；在這一因素以及降低成本的壓力下，開發外包變得非常普及；

       ●為了使分布在互連網上系統能夠互相協作，SOA成為一個熱點；

       ●互連網的普及，將原來分散開發人員彙總在一起，只要有一個合適的基礎和好的架構，他們就可以開發出產品級的工具軟體（以Eclipse，JBoss，MySQL，Subversion為例），從而開源成為了一種趨勢；

       ●B/S結構的系統非常容易升級，這使得軟體交付和升級的速度大大加快了（從以年月為單位，到以周天為單位）；

      回到正題，那麼在這些大的趨勢的作用下，軟體工程會如何發展呢？我覺得在未來幾年我們會看到如下的趨勢：

      ●需求工程，漸成熱點：專業化的角色，日益複雜的業務創新，全球分布的團隊以及互連網級的交付速度，這些都對需求萃取的正確性和有效性提出了更高的要求；我預計需求工程的研究和實施會成為近期的熱點，其中Use Case技術會被更廣泛而正確的應用，而相關工具的研發也會成為熱點（如IBM Rational Requirements Composer,，Ravenflow等。

      用例的優勢在於它天生是黑盒的，它用自然語言抽象了使用者和目標系統的互動，避免了混入分析、設計和實現細節，以保證用例可以被不懂具體技術的業務及測試人員所真正理解。同時，需求分析員又可以方便地通過用例分析（use case analysis）（即用分析類來試圖在理想方式下實現用例），將需求體系精華成分析模型。在這一過程中，需求分析員可以更進一步地完善基於用例的需求體系，而不必擔心分析模型會汙染需求，從而實現需求與分析的分離及有效互動。

       ●DSSA和MDD，老樹新花（基於領域的構架（DSSA）與模型驅動的開發（MDD））：隨著軟體應用的日益普及，軟體已經超出了將手動流程自動化的範疇，而開始成為業務創新的主要推動力。因此，引入捕獲特定領域內最先進需求及其實現架構的DSSA成為行業客戶的熱點之一。而且，DSSA的引入將MDD門檻大大降低了，也使基於DSSA的MDD支撐工具成為可能，從而可以極大地提高開發效率並保證軟體品質（例如，Telelogic的Rhapsody就是一個成功的基於即時嵌入式系統構架的MDD工具）。

       ●迭代/敏捷，漸成標準：隨著軟體交付周期的日益加快，迭代化開發已經成為大多數軟體Team Dev的必選項。但是迭代對整個團隊的需求、架構、協同及測試能力都提出了更高的要求，現在許多Team Dev都在試圖匯入迭代化開發的過程中，敏捷可是被看成迭代化開發的一種匯入方式，這不過敏捷的範圍其實比迭代化開發更大一些。

      敏捷的三個要素是反覆式開發法、坦誠合作和自適應性。坦誠合作其實才是敏捷的精髓，如Ivar所說，敏捷其實是有關Social Engineering的。敏捷的主要貢獻在於他更多地思考了如何去激發開發人員的工作熱情，這是在軟體工程幾十年的發展過程中相對被忽略的領域。

      ●持續整合，蓄勢待發：持續整合是保證迭代化開發品質的主要方式，通過持續整合可以利用自動化的方式來盡量自動地、儘早保證代碼品質。隨著迭代和敏捷的流行，持續整合相關的工具成為現在市場上的新熱點（如持續整合架構IBM Rational BuildForge, 開源軟體CruiseControl，代碼靜態分析工具Klocwork Insight，IBM Rational Software Analyzer等）。

      持續整合是一個複雜的系統工程，組織需要首先將現有的組態管理/變更管理工具與Build環境緊密整合並完成自動化Build過程，在根據企業/項目/產品的現狀，定義如何自動化地檢測軟體品質（代碼靜態分析、單元測試或煙霧測試 (Smoke Test)），並定義需要自動化產生的管理報表。

      ●基於實踐的過程架構，方興未艾：開發角色的專業化的和分布的全球化都要求軟體開發過程更加規範，而敏捷又要求過程必須緊密貼合項目的實際需要，因此傳統的大一統的過程無法符合這一需求。新一代的過程將是以實踐為核心的，項目可以通過組裝所需的不同實踐來獲得貼近項目要求的過程。IJI（Ivar Jacobson International）的EssWork和IBM Rational的RMC都是新一代的基於實踐的過程架構。

       依據過程專家長時間的經驗，他（她）們很小心、很仔細地將一個完整的開發過程組件化，從開發過程抽象出一個個可以被單獨匯入又可以被組裝到一起的實踐，從而使逐步求精式的流程改善成為可能。對於一個軟體組織而言，如果已經建立一個比較成熟的軟體開發流程，但覺得這一流程並不適合所有項目的實際需要，那麼目前可以考慮的是用實踐的方式去重新梳理現有流程，以使項目組能夠以實踐為單位來組裝出切合項目實際的流程；另外，該組織也可以將適用於主要組織的業界流行的實踐匯入到現有流程當中，IJI公司的專家從業界最佳經驗中抽取了八個實踐，有關資訊可訪問（http://www.esslab.net:4040/ngp/）。
 
      ●組態管理，昨日黃花：隨著Team Dev規模的日益減小，組態管理的複雜性大大降低了，我們注意到越來越多的使用者轉向使用開源的組態管理工具（如Subeverison，JIRA，hosted-projects等等）；未來的組態管理工具更多的以一種全生命週期管理平台（Application Lifecycle Management）的方式出現，弱化了單項的組態管理能力而強調了全流程的整合（如Microsoft VisualStudio Team System和IBM Rational Team Concert等）。

       即便組態管理的複雜性降低了，但它仍然是開發專案管理的最重要的支撐平台之一。目前的重點應該是加強對專案經理進行有關組態管理知識的培訓，讓他（她）們理解到組態管理能力（如並行開發、基準回退等等）能夠如何協助項目開發過程的，從而使組態管理工具/環境的價值能夠得到充分的發揮。
 
      作為結語，軟體工程對軟體開發的重要性我無須贅言了。雖然，我上面列出了一些軟體工程的熱點，但讀者一定要仔細分析組織自身特點以確定軟體工程的改進步驟，紮紮實實的逐步改進，而不應該盲目地追求熱點！