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

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

      在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。