企業信息化與軟件工程的迷思

企業信息化與軟件工程迷思

      在IT信息化過程當中，軟件工程技術持續演化，各個行業都須要IT信息化，信息系統融入基於平常工做中。 在一般軟件行業的公司內信息化每每比較健全，而非軟件行業的公司作得就相差甚遠。 非軟件行業公司在這兒，主要指非以軟件研發，電子商務互聯網爲首要贏利的公司與企業。 筆者曾經看到過某個國內上市公司，內部連一個門戶Protal都沒有。整個公司內部使有QQ作爲工做溝通與文件分享工具。一些上千人的國企公司也是如此，大都缺少信息安全意識，協做平臺。又如一個非軟件行業公司，自行組建研發團隊作信息系統研發。而這種狀況下，缺少熟悉對某個領域專業知識，加之業務部們對業務不精通，研發出來的系統每每流程低效。有些業務流程有問題，竟然也不作知道，甚至系統中一些業務邏輯錯誤操做的狀況。這也是領導者一個意識的問題，回到根本就是沒有深入理解企業信息化本質，以及未能從全局來規劃信息化，各處都是信息孤島。反思一個非軟件行業的公司須要CIO嗎？領導信息化意識差，更別談互聯網思惟。非軟件行業公司信息化如何作得好呢？ 大型公司通常會實施ERP，SCM。能夠看到是企業管理軟件ERP演變之一 特定行業領域信息化，看上去能夠是這樣的零售連鎖專賣信息化解決方案簡介之一，餐飲連鎖公司IT信息化解決方案一，某物流集團企業信息化案例介紹

      在信息系統研發過程當中，這自己也是一個軟件工程過程。按高層領導的想法想快速作一個系統，而他們認識裏面每每只有開發這個過程。對於軟件測試，部署，實施完成沒有意識。老是在不斷催促下開發一個信息系統。到最後，2個月系統開發完成。勉強投入使用，後面發現某個功能點又不能知足需求了。系統中BUG不斷出現，沒有辦法，不斷有工程師陷入到系統BUGS修復，維護過程當中。後續又想繼續作新項目時，發現人力資源徹底耗在遺留項目維護中了。這樣的領導每每不知道，修改程序比開發程序所花費的時間要大得多。接着出現的就是軟件系統存在質量問題，測試過程薄弱，發佈更新效率低的症狀。想實施成熟的CMMI，但企業急功近利的狀況下，徹底不現實。最後演化爲邊作邊改開發模式。開發工程師深受其苦，致使各種不標準，不規範的開發過程產生。項目在出現延期的跡象，但決策者不瞭解Brooks'Law：「往一個已經延誤的項目里加人力資源，只能讓那個項目更延誤」.

如何提升軟件系統質量呢？

     第一，需求階段。從軟件工程的源頭開始，需求是否充分分析，在需求不清楚的狀況下，作到敏捷需求開發。很大一部分取決於業務需求分析能力。在系統設計階段，非軟件行業的公司每每缺少，對系統分析設計深刻相對較少。系統沒有通過設計就開始進入編碼過程，最後沒有系統設計任何文字留下來。歷來沒有說敏捷開發，就不須要系統設計，架構設計。對於大型信息系統，架構設計更是重要。在RUP（Rational Unified Process），統一軟件開發過程，RUP最重要的它有三大特色：1）軟件開發是一個迭代過程，2）軟件開發是由Use Case驅動的，3）軟件開發是以架構設計（Architectural Design）爲中心的。在今天軟件研發過程當中，審視咱們可否快速的迭代就能發現不少問題，再看是否有Use Case，Use Case是否設計合理，第三是否有系統架構設計，設計是否知足質量屬性。

     第二，系統設計階段，分析和設計（Analysis & Design）工做流將需求轉化成將來系統的設計，爲系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽象，由設計類和一些描述組成。設計類被組織成具備良好接口的設計包（Package）和設計子系統（Subsystem），而描述則體現了類的對象如何協同工做實現用例的功能。設計活動以體系結構設計爲中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽象和簡化，該視圖中省略了一些細節，使重要的特色體現得更加清晰。體系結構不只僅是良好設計模型的承載媒介，並且在系統的開發中能提升被建立模型的質量。與建築學相似，若是軟件系統沒有一個好的架構是不可能成爲成功的軟件系統的。沒有圖紙的建築地、沒有設計的造橋工程都是不能夠想象的混亂世界。建築工程如是，軟件工程中亦然！架構設計是人們對一個結構內的元素及元素間關係的一種主觀映射的產物。架構設計是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。以前寫過一些，架構相關的文章，其中有數據庫的互聯網數據庫架構設計思路，對於企業架構涉及有企業架構轉型重構與治理，企業IT架構介紹。架構設計中軟件架構風格介紹，企業級應用架構模式N-Tier多層架構，軟件架構中質量特性。互聯網行業的電子商務基礎技術架構，互聯網電商搜索架構演化之一。咱們看到巨頭公司的：

      文件的橫向擴展。以Google的搜索技術爲例，文件被分割爲多個小塊並分別拷貝到多個服務器中。這樣搜索可並行地完成，並經過合併各個服務器所給出的結果獲得最終的搜索結果。
      架構的橫向擴展。以Amazon的作法爲例，事務會被切分爲多個服務，每一個服務使用特定服務器實現。當事務存在瓶頸時，可在多個服務器上覆制服務，而且每一個服務由一個半自治的「雙比薩」團隊負責。

     第三，編碼階段，在敏捷開發過程，說起能夠工做的軟件賽過面面俱到文檔。這就意味着咱們對源代碼質量要求比較高。源代碼可讀性，可維護性、可測試性尤爲重要，還有性能。如何作到代碼優雅，《The Art of Readable Code》一書已作詳細描述。一個優秀的程序員效率超過10/100個廣泛的程序員。有了優質的源代碼，後續可能出現的BUGS就相對較少。全部一個大型軟件產商，他們最重要一個過程就是Code Review. 其次開發人員，須要自行編寫單元測試。在不少小公司這一起徹底沒有，不少人寫幾年程序員竟然不知道單元測試，這也就是非軟件行業的環境造就的問題。也是體現專業性。以前這篇文章也談到軟件開發的專業化 ，還有有提到 靜態代碼分析與代碼質量安全 。

     第三，測試階段。迭代的方法，意味着在整個項目中進行測試，從而儘量早地發現缺陷，從根本上下降了修改缺陷的成本。從全面質量管理，測試能力成熟度TMM，到全面的軟件測試。以及敏捷軟件質量保證的方法與實踐。 微軟，GOOGLE等公司把軟件測試推上更高臺階。誕生了SDET這樣職位。SDET，屬於開發和測試中間，屬於白盒測試範疇，要求發現代碼中的問題。SDET要求人員對質量的要求很高，而且喜歡拆東西，弄明白它是怎麼工做的，並且喜歡改善它。一個SDET的最基本要求就是對質量的熱情：必定要找到全部的瑕疵從而達到完美。其次，喜歡鑽研、分析、並改善事物是成功的SDET的又一潛質。在今天移動互聯網時間，須要移動應用App測試與質量管理一， 構建移動應用測試(一)，咱們須要基本的IT持續集成之質量管理，到底自動化測試作什麼，梳理流程軟件測試流程參考一，同時演化DevOps的基本原則與介紹

     第四，部署發佈階段。工做流的目的是成功的生成版本並將軟件分發給最終用戶。部署工做流描述了那些與確保軟件產品對最終用戶具備可用性相關的活動，包括：軟件打包、生成軟件自己之外的產品、安裝軟件、爲用戶提供幫助。咱們須要構建高效的研發與自動化運維。涉及運維，以前說起IT運維監控解決方案介紹，技術架構下的運維治理。也有移動端運維體系建設. Infrastructure As Code ，對着容器、容器編排技術進行編碼，讓「無人值守」、「智能運維」真正成爲可能。持續集成（Continuous Integration）、持續交付（Continuous Delivery）、持續運維（Continuous Operation）是DevOps的具體環節和手段，它至關於把一條純數字化鏈路上不一樣的參與者關聯到一塊兒 – 不管是開發工程師仍是運維工程師

總體

     從整個研發生命週期中軟件研發工程基礎設施，移動開發一站式解決方案。咱們如何解決技術債務管理計劃。既然是個工程，咱們還須要軟件項目進度管理，一些企業在項目管理上的創新企業項目化管理介紹。說到最後不管是信息化建設，軟件系統研發最關鍵3個要素是人，過程，技術。人是首位，人構成組織，須要學習型組織與企業，人須要管理企業績效管理系統之平衡記分卡，這又與公司文化有關係，咱們看人才公司環境與企業文化，企業文化、團隊文化與知識共享，企業創新文化與等級觀念的做用.

趨勢

     愈來愈多的系統正在向雲上遷移，雲就是將來。相比於大多數預製的數據中心，雲更便宜、更穩定、更安全而且更具擴展性。將已有的應用轉化爲基於雲的應用是十分具備挑戰性的。針對傳統數據架構所設計的應用若是不作大量的代碼重構工做，就沒法在雲中很好地運行。架構即代碼解決方案：使用容器，實現了過程的標準化和自動化，容器影響開發者的開發方式、開發習慣，「強迫」他們去思考例如無狀態的服務、業務邏輯粒度的控制、資源的彈性伸縮、應用代碼的發佈形態、系統裏面每個細節的可監控性等等。無服務器架構，以更低的價格提供了靈活的計算容量，軟件定義網絡，使用軟件而非硬件實現了規模擴展。 Conversations as a Platform（CaaP）引導人工智能, Containers as a Service (CaaS) 引導持續交付。再到響應式編程宣言的出現，軟件開發項目經歷了一些重大的重構：構建自組織的團隊模式，以增量和迭代的方式構建健壯的產品，從客戶那得到快速反饋從而通知正在進行的工做。據Gartner稱，2020年企業中無雲戰略將極爲罕見。

     企業數據庫是一個巨大的依賴性生成器。因爲每一個獨立團隊的工做必需要和其它共享同一數據庫的團隊協做，這致使每一個團隊都沒法實現自治的部署。聯邦架構是單一數據庫的替代技術，它將數據分割爲適合各個獨立模塊或服務需求的本地數據存儲，數據的存取只能經過API方法。API正在替代中央共享數據庫，並使物聯網成爲可能。使用API是軟件工程的必備技術。API應做爲有具體團隊負責的產品看待，並經過聚焦於API用戶來推動和開發新的功能。
     沒有必要盡力去實現系統零故障，咱們能夠換一種思惟。當前不少的系統都是脆弱的，雖然它們在剛上線時都是魯棒的，可是隨着時間的進展，它們變得愈加地難以維護。當今系統須要的是反脆弱，並具備面對故障的能力。在發生故障時，系統應能限定損害的程度，並從故障中恢復。如何獲取反脆弱系統取決於系統測試的方法，即如何經過注入故障產生給定的運行錯誤。爲達到所指望的可用性和魯棒性等級，系統須要隔離故障並從故障自動恢復。
     爲具有持續集成的能力，須要一個部署流水線；爲得到持續集成所承諾的優勢，須要具備一個包括產品管理、測試和運營的跨功能團隊。部署流水線依賴於自動的測試、遷移和部署過程。持續集成須要全部團隊經過代碼庫作交流，實現針對主幹分支的持續集成。團隊應維持軟件時常處於發佈就緒的狀態，若是事實並不是如此，你必須停下來並作到上述要求。只要實現了持續的部署，一旦有用的軟件增量或功能就緒，就可經過切換或轉換實現軟件的增量發佈。
     持續交付提供了必要的端到端反饋。研究顯示在半數狀況下產品經理是錯的，產品規格說明中會有三分之二的特性和功能是沒有必要的。致使這些問題產生的緣由在於作實驗驗證某個特性是否能夠真正地解決手頭問題以前，就試圖達成具體開發特性的細節。爲確保開發的解決方案能很好地適用於所需解決問題，須要經過實際的使用產生快速的反饋，這也正是精益開發和敏捷開發實踐的真正價值所在。

     咱們要讓IT技術驅動業務，提高協做效率，下降運營成本，提升ROI。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

但願對您軟件項目開發,運維管理，系統架構與研發管理體系, 信息安全, 企業信息化等有幫助。 其它您可能感興趣的文章：
雲計算參考架構幾例
微服務與Docker介紹
互聯網直播平臺架構案例一
高可用架構案例一
某互聯網公司廣告平臺技術架構
某大型電商雲平臺實踐
雲計算參考架構幾例
移動應用App測試與質量管理一
全面的軟件測試
著名ERP廠商的SSO單點登陸解決方案介紹一
軟件項目風險管理介紹
企業項目化管理介紹
智能企業與信息化之一
由企業家基本素質想到的
敏捷軟件質量保證的方法與實踐
構建高效的研發與自動化運維
IT運維監控解決方案介紹
IT持續集成之質量管理
人才公司環境與企業文化
企業績效管理系統之平衡記分卡
企業文化、團隊文化與知識共享
高效能的團隊建設
餐飲連鎖公司IT信息化解決方案一

若有想了解更多軟件研發 , 系統 IT集成 , 企業信息化，項目管理，企業管理 等資訊，請關注個人微信訂閱號：

 

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。
該文章也同時發佈在個人獨立博客中-Petter Liu Blog。