企業(yè)信息化與軟件工程迷思

      在IT信息化過程中，軟件工程技術(shù)持續(xù)演化，各個(gè)行業(yè)都需要IT信息化，信息系統(tǒng)融入基于日常工作中。 在通常軟件行業(yè)的公司內(nèi)信息化往往比較健全，而非軟件行業(yè)的公司做得就相差甚遠(yuǎn)。 非軟件行業(yè)公司在這兒，主要指非以軟件研發(fā)，電子商務(wù)互聯(lián)網(wǎng)為首要贏利的公司與企業(yè)。 筆者曾經(jīng)看到過某個(gè)國內(nèi)上市公司，內(nèi)部連一個(gè)門戶Protal都沒有。整個(gè)公司內(nèi)部使有QQ做為工作溝通與文件分享工具。一些上千人的國企公司也是如此，大都缺乏信息安全意識(shí)，協(xié)作平臺(tái)。又如一個(gè)非軟件行業(yè)公司，自行組建研發(fā)團(tuán)隊(duì)做信息系統(tǒng)研發(fā)。而這種情況下，缺乏熟悉對(duì)某個(gè)領(lǐng)域?qū)I(yè)知識(shí)，加之業(yè)務(wù)部們對(duì)業(yè)務(wù)不精通，研發(fā)出來的系統(tǒng)往往流程低效。有些業(yè)務(wù)流程有問題，居然也不做知道，甚至系統(tǒng)中一些業(yè)務(wù)邏輯錯(cuò)誤操作的情況。這也是領(lǐng)導(dǎo)者一個(gè)意識(shí)的問題，回到根本就是沒有深刻理解企業(yè)信息化本質(zhì)，以及未能從全局來規(guī)劃信息化，各處都是信息孤島。反思一個(gè)非軟件行業(yè)的公司需要CIO嗎？領(lǐng)導(dǎo)信息化意識(shí)差，更別談互聯(lián)網(wǎng)思維。非軟件行業(yè)公司信息化如何做得好呢？ 大型公司一般會(huì)實(shí)施ERP，SCM。可以看到是企業(yè)管理軟件ERP演變之一 特定行業(yè)領(lǐng)域信息化，看上去可以是這樣的零售連鎖專賣信息化解決方案簡介之一，餐飲連鎖公司IT信息化解決方案一，某物流集團(tuán)企業(yè)信息化案例介紹

      在信息系統(tǒng)研發(fā)過程中，這本身也是一個(gè)軟件工程過程。按高層領(lǐng)導(dǎo)的想法想快速做一個(gè)系統(tǒng)，而他們認(rèn)識(shí)里面往往只有開發(fā)這個(gè)過程。對(duì)于軟件測(cè)試，部署，實(shí)施完成沒有意識(shí)。總是在不斷催促下開發(fā)一個(gè)信息系統(tǒng)。到最后，2個(gè)月系統(tǒng)開發(fā)完成。勉強(qiáng)投入使用，后面發(fā)現(xiàn)某個(gè)功能點(diǎn)又不能滿足需求了。系統(tǒng)中BUG不斷出現(xiàn)，沒有辦法，不斷有工程師陷入到系統(tǒng)BUGS修復(fù)，維護(hù)過程中。后續(xù)又想繼續(xù)做新項(xiàng)目時(shí)，發(fā)現(xiàn)人力資源完全耗在遺留項(xiàng)目維護(hù)中了。這樣的領(lǐng)導(dǎo)往往不知道，修改程序比開發(fā)程序所花費(fèi)的時(shí)間要大得多。接著出現(xiàn)的就是軟件系統(tǒng)存在質(zhì)量問題，測(cè)試過程薄弱，發(fā)布更新效率低的癥狀。想實(shí)施成熟的CMMI，但企業(yè)急功近利的情況下，完全不現(xiàn)實(shí)。最后演化為邊做邊改開發(fā)模式。開發(fā)工程師深受其苦，導(dǎo)致各類不標(biāo)準(zhǔn)，不規(guī)范的開發(fā)過程產(chǎn)生。項(xiàng)目在出現(xiàn)延期的跡象，但決策者不了解Brooks'Law：“往一個(gè)已經(jīng)延誤的項(xiàng)目里加人力資源，只能讓那個(gè)項(xiàng)目更延誤”.

如何提高軟件系統(tǒng)質(zhì)量呢？

     第一，需求階段。從軟件工程的源頭開始，需求是否充分分析，在需求不清楚的情況下，做到敏捷需求開發(fā)。很大一部分取決于業(yè)務(wù)需求分析能力。在系統(tǒng)設(shè)計(jì)階段，非軟件行業(yè)的公司往往缺乏，對(duì)系統(tǒng)分析設(shè)計(jì)深入相對(duì)較少。系統(tǒng)沒有經(jīng)過設(shè)計(jì)就開始進(jìn)入編碼過程，最后沒有系統(tǒng)設(shè)計(jì)任何文字留下來。從來沒有說敏捷開發(fā)，就不需要系統(tǒng)設(shè)計(jì)，架構(gòu)設(shè)計(jì)。對(duì)于大型信息系統(tǒng)，架構(gòu)設(shè)計(jì)更是重要。在RUP（Rational Unified Process），統(tǒng)一軟件開發(fā)過程，RUP最重要的它有三大特點(diǎn)：1）軟件開發(fā)是一個(gè)迭代過程，2）軟件開發(fā)是由Use Case驅(qū)動(dòng)的，3）軟件開發(fā)是以架構(gòu)設(shè)計(jì)（Architectural Design）為中心的。在今天軟件研發(fā)過程中，審視我們能否快速的迭代就能發(fā)現(xiàn)很多問題，再看是否有Use Case，Use Case是否設(shè)計(jì)合理，第三是否有系統(tǒng)架構(gòu)設(shè)計(jì)，設(shè)計(jì)是否滿足質(zhì)量屬性。

     第二，系統(tǒng)設(shè)計(jì)階段，分析和設(shè)計(jì)（Analysis & Design）工作流將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計(jì)，為系統(tǒng)開發(fā)一個(gè)健壯的結(jié)構(gòu)并調(diào)整設(shè)計(jì)使其與實(shí)現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設(shè)計(jì)的結(jié)果是一個(gè)設(shè)計(jì)模型和一個(gè)可選的分析模型。設(shè)計(jì)模型是源代碼的抽象，由設(shè)計(jì)類和一些描述組成。設(shè)計(jì)類被組織成具有良好接口的設(shè)計(jì)包（Package）和設(shè)計(jì)子系統(tǒng)（Subsystem），而描述則體現(xiàn)了類的對(duì)象如何協(xié)同工作實(shí)現(xiàn)用例的功能。設(shè)計(jì)活動(dòng)以體系結(jié)構(gòu)設(shè)計(jì)為中心，體系結(jié)構(gòu)由若干結(jié)構(gòu)視圖來表達(dá)，結(jié)構(gòu)視圖是整個(gè)設(shè)計(jì)的抽象和簡化，該視圖中省略了一些細(xì)節(jié)，使重要的特點(diǎn)體現(xiàn)得更加清晰。體系結(jié)構(gòu)不僅僅是良好設(shè)計(jì)模型的承載媒介，而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質(zhì)量。與建筑學(xué)類似，如果軟件系統(tǒng)沒有一個(gè)好的架構(gòu)是不可能成為成功的軟件系統(tǒng)的。沒有圖紙的建筑地、沒有設(shè)計(jì)的造橋工程都是不可以想象的混亂世界。建筑工程如是，軟件工程中亦然！架構(gòu)設(shè)計(jì)是人們對(duì)一個(gè)結(jié)構(gòu)內(nèi)的元素及元素間關(guān)系的一種主觀映射的產(chǎn)物。架構(gòu)設(shè)計(jì)是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。之前寫過一些，架構(gòu)相關(guān)的文章，其中有數(shù)據(jù)庫的互聯(lián)網(wǎng)數(shù)據(jù)庫架構(gòu)設(shè)計(jì)思路，對(duì)于企業(yè)架構(gòu)涉及有企業(yè)架構(gòu)轉(zhuǎn)型重構(gòu)與治理，企業(yè)IT架構(gòu)介紹。架構(gòu)設(shè)計(jì)中軟件架構(gòu)風(fēng)格介紹，企業(yè)級(jí)應(yīng)用架構(gòu)模式N-Tier多層架構(gòu)，軟件架構(gòu)中質(zhì)量特性。互聯(lián)網(wǎng)行業(yè)的電子商務(wù)基礎(chǔ)技術(shù)架構(gòu)，互聯(lián)網(wǎng)電商搜索架構(gòu)演化之一。我們看到巨頭公司的：

      文件的橫向擴(kuò)展。以Google的搜索技術(shù)為例，文件被分割為多個(gè)小塊并分別拷貝到多個(gè)服務(wù)器中。這樣搜索可并行地完成，并通過合并各個(gè)服務(wù)器所給出的結(jié)果得到最終的搜索結(jié)果。
      架構(gòu)的橫向擴(kuò)展。以Amazon的做法為例，事務(wù)會(huì)被切分為多個(gè)服務(wù)，每個(gè)服務(wù)使用特定服務(wù)器實(shí)現(xiàn)。當(dāng)事務(wù)存在瓶頸時(shí)，可在多個(gè)服務(wù)器上復(fù)制服務(wù)，并且每個(gè)服務(wù)由一個(gè)半自治的“雙比薩”團(tuán)隊(duì)負(fù)責(zé)。

     第三，編碼階段，在敏捷開發(fā)過程，提及可以工作的軟件勝過面面俱到文檔。這就意味著我們對(duì)源代碼質(zhì)量要求比較高。源代碼可讀性，可維護(hù)性、可測(cè)試性尤其重要，還有性能。如何做到代碼優(yōu)雅，《The Art of Readable Code》一書已做詳細(xì)描述。一個(gè)優(yōu)秀的程序員效率超過10/100個(gè)普遍的程序員。有了優(yōu)質(zhì)的源代碼，后續(xù)可能出現(xiàn)的BUGS就相對(duì)較少。所有一個(gè)大型軟件產(chǎn)商，他們最重要一個(gè)過程就是Code Review. 其次開發(fā)人員，需要自行編寫單元測(cè)試。在很多小公司這一塊兒完全沒有，很多人寫幾年程序員居然不知道單元測(cè)試，這也就是非軟件行業(yè)的環(huán)境造就的問題。也是體現(xiàn)專業(yè)性。之前這篇文章也談到軟件開發(fā)的專業(yè)化 ，還有有提到 靜態(tài)代碼分析與代碼質(zhì)量安全 。

     第三，測(cè)試階段。迭代的方法，意味著在整個(gè)項(xiàng)目中進(jìn)行測(cè)試，從而盡可能早地發(fā)現(xiàn)缺陷，從根本上降低了修改缺陷的成本。從全面質(zhì)量管理，測(cè)試能力成熟度TMM，到全面的軟件測(cè)試。以及敏捷軟件質(zhì)量保證的方法與實(shí)踐。 微軟，GOOGLE等公司把軟件測(cè)試推上更高臺(tái)階。誕生了SDET這樣職位。SDET，屬于開發(fā)和測(cè)試中間，屬于白盒測(cè)試范疇，要求發(fā)現(xiàn)代碼中的問題。SDET要求人員對(duì)質(zhì)量的要求很高，并且喜歡拆東西，弄明白它是怎么工作的，而且喜歡改善它。一個(gè)SDET的最基本要求就是對(duì)質(zhì)量的熱情：一定要找到所有的瑕疵從而達(dá)到完美。其次，喜歡鉆研、分析、并改善事物是成功的SDET的又一潛質(zhì)。在今天移動(dòng)互聯(lián)網(wǎng)時(shí)間，需要移動(dòng)應(yīng)用App測(cè)試與質(zhì)量管理一， 構(gòu)建移動(dòng)應(yīng)用測(cè)試(一)，我們需要基本的IT持續(xù)集成之質(zhì)量管理，到底自動(dòng)化測(cè)試做什么，梳理流程軟件測(cè)試流程參考一，同時(shí)演化DevOps的基本原則與介紹

     第四，部署發(fā)布階段。工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對(duì)最終用戶具有可用性相關(guān)的活動(dòng)，包括：軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。我們需要構(gòu)建高效的研發(fā)與自動(dòng)化運(yùn)維。涉及運(yùn)維，之前提及IT運(yùn)維監(jiān)控解決方案介紹，技術(shù)架構(gòu)下的運(yùn)維治理。也有移動(dòng)端運(yùn)維體系建設(shè). Infrastructure As Code ，對(duì)著容器、容器編排技術(shù)進(jìn)行編碼，讓“無人值守”、“智能運(yùn)維”真正成為可能。持續(xù)集成（Continuous Integration）、持續(xù)交付（Continuous Delivery）、持續(xù)運(yùn)維（Continuous Operation）是DevOps的具體環(huán)節(jié)和手段，它相當(dāng)于把一條純數(shù)字化鏈路上不同的參與者關(guān)聯(lián)到一起 – 無論是開發(fā)工程師還是運(yùn)維工程師

整體

     從整個(gè)研發(fā)生命周期中軟件研發(fā)工程基礎(chǔ)設(shè)施，移動(dòng)開發(fā)一站式解決方案。我們?nèi)绾谓鉀Q技術(shù)債務(wù)管理計(jì)劃。既然是個(gè)工程，我們還需要軟件項(xiàng)目進(jìn)度管理，一些企業(yè)在項(xiàng)目管理上的創(chuàng)新企業(yè)項(xiàng)目化管理介紹。說到最后不論是信息化建設(shè)，軟件系統(tǒng)研發(fā)最關(guān)鍵3個(gè)要素是人，過程，技術(shù)。人是首位，人構(gòu)成組織，需要學(xué)習(xí)型組織與企業(yè)，人需要管理企業(yè)績效管理系統(tǒng)之平衡記分卡，這又與公司文化有關(guān)系，我們看人才公司環(huán)境與企業(yè)文化，企業(yè)文化、團(tuán)隊(duì)文化與知識(shí)共享，企業(yè)創(chuàng)新文化與等級(jí)觀念的作用.

趨勢(shì)

     越來越多的系統(tǒng)正在向云上遷移，云就是未來。相比于大多數(shù)預(yù)制的數(shù)據(jù)中心，云更便宜、更穩(wěn)定、更安全并且更具擴(kuò)展性。將已有的應(yīng)用轉(zhuǎn)化為基于云的應(yīng)用是十分具有挑戰(zhàn)性的。針對(duì)傳統(tǒng)數(shù)據(jù)架構(gòu)所設(shè)計(jì)的應(yīng)用如果不做大量的代碼重構(gòu)工作，就無法在云中很好地運(yùn)行。架構(gòu)即代碼解決方案：使用容器，實(shí)現(xiàn)了過程的標(biāo)準(zhǔn)化和自動(dòng)化，容器影響開發(fā)者的開發(fā)方式、開發(fā)習(xí)慣，“強(qiáng)迫”他們?nèi)ニ伎祭?strong>無狀態(tài)的服務(wù)、業(yè)務(wù)邏輯粒度的控制、資源的彈性伸縮、應(yīng)用代碼的發(fā)布形態(tài)、系統(tǒng)里面每一個(gè)細(xì)節(jié)的可監(jiān)控性等等。無服務(wù)器架構(gòu)，以更低的價(jià)格提供了靈活的計(jì)算容量，軟件定義網(wǎng)絡(luò)，使用軟件而非硬件實(shí)現(xiàn)了規(guī)模擴(kuò)展。 Conversations as a Platform（CaaP）引導(dǎo)人工智能, Containers as a Service (CaaS) 引導(dǎo)持續(xù)交付。再到響應(yīng)式編程宣言的出現(xiàn)，軟件開發(fā)項(xiàng)目經(jīng)歷了一些重大的重構(gòu)：構(gòu)建自組織的團(tuán)隊(duì)模式，以增量和迭代的方式構(gòu)建健壯的產(chǎn)品，從客戶那獲得快速反饋從而通知正在進(jìn)行的工作。據(jù)Gartner稱，2020年企業(yè)中無云戰(zhàn)略將極為罕見。

     企業(yè)數(shù)據(jù)庫是一個(gè)巨大的依賴性生成器。由于每個(gè)獨(dú)立團(tuán)隊(duì)的工作必須要和其它共享同一數(shù)據(jù)庫的團(tuán)隊(duì)協(xié)作，這導(dǎo)致每個(gè)團(tuán)隊(duì)都無法實(shí)現(xiàn)自治的部署。聯(lián)邦架構(gòu)是單一數(shù)據(jù)庫的替代技術(shù)，它將數(shù)據(jù)分割為適合各個(gè)獨(dú)立模塊或服務(wù)需求的本地?cái)?shù)據(jù)存儲(chǔ)，數(shù)據(jù)的存取只能通過API方法。API正在替代中央共享數(shù)據(jù)庫，并使物聯(lián)網(wǎng)成為可能。使用API是軟件工程的必備技術(shù)。API應(yīng)作為有具體團(tuán)隊(duì)負(fù)責(zé)的產(chǎn)品看待，并通過聚焦于API用戶來推進(jìn)和開發(fā)新的功能。
     沒有必要盡力去實(shí)現(xiàn)系統(tǒng)零故障，我們可以換一種思維。當(dāng)前很多的系統(tǒng)都是脆弱的，雖然它們?cè)趧偵暇€時(shí)都是魯棒的，但是隨著時(shí)間的進(jìn)展，它們變得越發(fā)地難以維護(hù)。當(dāng)今系統(tǒng)需要的是反脆弱，并具有面對(duì)故障的能力。在發(fā)生故障時(shí)，系統(tǒng)應(yīng)能限定損害的程度，并從故障中恢復(fù)。如何獲取反脆弱系統(tǒng)取決于系統(tǒng)測(cè)試的方法，即如何通過注入故障產(chǎn)生給定的運(yùn)行錯(cuò)誤。為達(dá)到所期望的可用性和魯棒性等級(jí)，系統(tǒng)需要隔離故障并從故障自動(dòng)恢復(fù)。
     為具備持續(xù)集成的能力，需要一個(gè)部署流水線；為獲得持續(xù)集成所承諾的優(yōu)點(diǎn)，需要具有一個(gè)包括產(chǎn)品管理、測(cè)試和運(yùn)營的跨功能團(tuán)隊(duì)。部署流水線依賴于自動(dòng)的測(cè)試、遷移和部署過程。持續(xù)集成需要所有團(tuán)隊(duì)通過代碼庫做交流，實(shí)現(xiàn)針對(duì)主干分支的持續(xù)集成。團(tuán)隊(duì)?wèi)?yīng)維持軟件時(shí)常處于發(fā)布就緒的狀態(tài)，如果事實(shí)并非如此，你必須停下來并做到上述要求。只要實(shí)現(xiàn)了持續(xù)的部署，一旦有用的軟件增量或功能就緒，就可通過切換或轉(zhuǎn)換實(shí)現(xiàn)軟件的增量發(fā)布。
     持續(xù)交付提供了必要的端到端反饋。研究顯示在半數(shù)情況下產(chǎn)品經(jīng)理是錯(cuò)的，產(chǎn)品規(guī)格說明中會(huì)有三分之二的特性和功能是沒有必要的。導(dǎo)致這些問題產(chǎn)生的原因在于做實(shí)驗(yàn)驗(yàn)證某個(gè)特性是否可以真正地解決手頭問題之前，就試圖達(dá)成具體開發(fā)特性的細(xì)節(jié)。為確保開發(fā)的解決方案能很好地適用于所需解決問題，需要通過實(shí)際的使用產(chǎn)生快速的反饋，這也正是精益開發(fā)和敏捷開發(fā)實(shí)踐的真正價(jià)值所在。

     我們要讓IT技術(shù)驅(qū)動(dòng)業(yè)務(wù)，提升協(xié)作效率，降低運(yùn)營成本，提高ROI。

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

希望對(duì)您軟件項(xiàng)目開發(fā),運(yùn)維管理，系統(tǒng)架構(gòu)與研發(fā)管理體系, 信息安全, 企業(yè)信息化等有幫助。 其它您可能感興趣的文章：
云計(jì)算參考架構(gòu)幾例
微服務(wù)與Docker介紹
互聯(lián)網(wǎng)直播平臺(tái)架構(gòu)案例一
高可用架構(gòu)案例一
某互聯(lián)網(wǎng)公司廣告平臺(tái)技術(shù)架構(gòu)
某大型電商云平臺(tái)實(shí)踐
云計(jì)算參考架構(gòu)幾例
移動(dòng)應(yīng)用App測(cè)試與質(zhì)量管理一
全面的軟件測(cè)試
著名ERP廠商的SSO單點(diǎn)登錄解決方案介紹一
軟件項(xiàng)目風(fēng)險(xiǎn)管理介紹
企業(yè)項(xiàng)目化管理介紹
智能企業(yè)與信息化之一
由企業(yè)家基本素質(zhì)想到的
敏捷軟件質(zhì)量保證的方法與實(shí)踐
構(gòu)建高效的研發(fā)與自動(dòng)化運(yùn)維
IT運(yùn)維監(jiān)控解決方案介紹
IT持續(xù)集成之質(zhì)量管理
人才公司環(huán)境與企業(yè)文化
企業(yè)績效管理系統(tǒng)之平衡記分卡
企業(yè)文化、團(tuán)隊(duì)文化與知識(shí)共享
高效能的團(tuán)隊(duì)建設(shè)
餐飲連鎖公司IT信息化解決方案一

如有想了解更多軟件研發(fā) , 系統(tǒng) IT集成 , 企業(yè)信息化，項(xiàng)目管理，企業(yè)管理 等資訊，請(qǐng)關(guān)注我的微信訂閱號(hào)：

作者：Petter Liu
出處：http://www.rzrgm.cn/wintersun/
本文版權(quán)歸作者和博客園共有，歡迎轉(zhuǎn)載，但未經(jīng)作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責(zé)任的權(quán)利。
該文章也同時(shí)發(fā)布在我的獨(dú)立博客中-Petter Liu Blog。