歡迎光臨天絡科技
深圳站:0755-88291481
400-800-4428

穿越火线3月6号:降低與軟件相關的商務風險需要系統的視角

       【賽迪網訊】當下,與軟件相關的商務風險是一個很嚴峻的問題。這些風險還嚴重威脅到軟件系統的安全性,可靠性,性能效率和可維護性。
        目前IT軟件質量聯盟(CISQ)已經發布了軟件質量評估的產業框架,CISO是致力于將開發軟件規模和源代碼結構質量測試國際標準化的IT行業領導小組,CISO由對象管理組(OMG)和軟件工程研究所(SEI)在卡內基梅隆大學聯合成立。
        風險的評估可以分為兩個層級,組件和系統級,利用這兩個層級的評估,風險可以被有效降低。市面上對應這兩個層級已有可用的功能強大的靜態代碼分析工具,而選擇哪個層級則取決于系統在其生命周期中的位置。
        系統化地管理軟件風險可以讓軟件架構師和工程師免于一些機械化的工作,為他們專注于其他工作和創新節約了寶貴的時間,從而幫助公司獲得更多的商務效益。不僅如此,管理軟件風險還能加快公司發展速度,降低系統中斷或安全漏洞的出現幾率,讓公司更有力地參與到當前和未來的商業競爭中。
        日前,卡特財團(Cutter Consortium)?Peter Kaminski與Tomlin Coggeshall,在卡特財團的《通過軟件語境分析降低業務風險和解鎖軟件潛力》報告中,指出:“降低單個商務風險十分容易,與軟件相關的商務風險在所有的商務風險中占比越來越大,因此,降低軟件風險的解決方案已成為當今商業發展的一部分。目前,用戶可以在軟件資產和開發項目的組合過程中應用一組工具和方法來管理軟件風險。對于數字化時代的企業及組織來說,工業化地管理軟件風險是至關重要的,它能解放了開發人員的“聰明才智”,使他們能專研于構建和交付應用程序等更加困難的部分,同時也能確保應用程序在任何時刻都不會有風險,最大化地利用好人類智能和軟件智能?!?br>         軟件的組織結構和軟件風險
        目前,許多IT機構的組織架構都不利于有效地管理軟件風險,那么從組織上來看,誰應該負責管理軟件風險呢?
首席信息安全官(CISO)負責系統的整體安全,但是這個人可能不會直接參與到日常的應用程序開發中,此外,CISO并不需要對可靠性、性能效率和可維護性三種類型的軟件風險負責。
        架構師負責建立架構標準,以確定開發人員在開發應用程序過程中如何降低風險,但是在構建應用程序時,架構師常常不會參與開發環節。
        因此,開發工作可能會無意中在架構團隊不知情的情況下偏離了目標體系結構。
        QA工程師名義上負責產品質量和降低軟件風險,但是他們缺乏對軟件設計方法的洞察力,導致他們無法測試邊界情況和其他盲點。通常,他們甚至沒有時間來測試所有的功能,而測試才是他們的主要關注點。因此,降低軟件風險的責任在默認情況下留給了開發人員。
        這對于在開發人員掌控范圍內的風險是有意義的;但是,隨著應用程序、新架構框架和交付速度的不斷增長和日漸復雜,開發人員可能對整個現代軟件系統失去了深刻的了解,這種現狀成了大多數公司和組織都無法克服的盲點,而這種盲點在那些對業務至關重要的部分——核心應用程序的安全性和可靠性方面顯得尤為突出。
        我們的建議是,產品管理或產品負責人應該對管理和降低產品風險負主要責任,他們可以使用軟件語境分析工具并分配相應的工程團隊來解決這個問題。
        風險:質量的另一面
        我們首先必須承認,有興趣構建彈性,快速,靈敏,安全和有保障的系統的IT領導者通?;嵋浴叭砑柿俊倍皇恰叭砑縵鍘崩刺嘎壅飧齷疤?。也就是說,他們傾向于描述一個積極的結果,而不是避免消極的結果。
對于負責軟件系統部署的人員來說,為了盡可能完美地分析商務風險,比較合適的做法應該是平等地看待積極(軟件質量)結果和負面(軟件風險)結果。
        在單元層面上,隨著軟件組件的工作進展及其功能需求變化,開發人員可以引入或修復問題。但是,這種修復是沒有考慮系統其余部分的情況下進行的,開發人員也不想忽略其他部分,只是他們缺少對整個系統的了解,所以他們只能改動自己負責的組件。
        系統級問題一般在架構級別產生或修復,常源于整個系統組件之間,這些組件和軟件架構師的設計、產品經理的非功能需求這兩種語境以及與用戶、數據庫這些外部組件的交互。由于當今系統的規模和復雜程度不斷增加,開發人員、測試人員或架構師需要在軟件分析工具的幫助下才能看到系統問題。
        軟件風險的種類
        標準的第二個維度是類型,我們將軟件風險問題分為四個主要的類別。
        1.安全性問題,如泄露隱私,數據和特權等的漏洞。顯然這些可能會有災難性的后果。常見弱點枚舉是一個比較知名的安全問題的標準化列表,表中已經包括了1,005種安全錯誤。
        2.可靠性問題,如系統?;奔?,數據損壞以及系統從中斷恢復的能力。
        3.性能問題,當用戶有大量的計算需求時軟件系統可能無法及時響應,系統響應時間長,應用可擴展性變差,影響員工生產力和用戶滿意度。
        4.最后,當軟件架構不完整時,會出現可維護性的風險,結每個問題修復所需要的時間特別長,導致軟件系統無法應對不斷變化的市場條件,或在修改過程中,維護成本過高。
        運行、構建、轉換
        在本節中,讓我們使用一個能檢查軟件風險的透鏡。
        大部分公司及企業已有成套的軟件系統,公司領導已做好趕超競爭對手的發展規劃。而軟件風險和降低風險的工作在每個項目生命周期中大不相同,因此如何分析各種類型的風險及其出現的幾率值得我們研究。
        運行:構建什么
        對于一般的系統來說,軟件風險的大部分都分布在系統級別。在這個假定的場景中,這個項目已經整體集成和部署完成,單位級的風險幾乎都被消除了。
        此時,安全性檢查在測試項目的部署使用階段仍要進行,這包括對已知架構的系統安全問題的定期滲透測試和審查,這是因為針對舊的架構,新型的攻擊可能已經被開發出來了?!熬傻母踩?,舊的系統可能不太容易有安全漏洞的想法已被證明是錯誤的,例如,美國聯邦機構最近對系統的研究表明,具有更多以前遺留系統的聯邦機構可能會有比采用新系統的機構有更多的安全漏洞。
        可靠性和性能效率必須被時刻監測;但如果他們長期保持一個穩定的的趨勢,也沒有不斷加強或現代化的必要,則不必予以過多關注。有些系統,在上述的生命周期模式下,由于監管變更或規范性的原因,依然需要偶爾升級,雖然由于系統時代變化,缺少對代碼庫的了解,缺乏相應的專業知識而讓這種升級很困難,但就像新建一個系統的工作一樣,升級依然是必不可少的。
        系統的可維護性在系統的整個生命周期中,甚至包括以前的部署,都是非常重要的。安全補丁、對庫和操作系統的升級,以及開發人員對系統內容的編寫修改及維護都非常重要。最后,一個說明項目大致內容和項目規模的文檔是必要的,用戶清楚系統內容有助于后期維護。
        文檔覆蓋范圍應包括系統的組成,它所涉及的其他系統和進程,規模和對應的度量系統的大小和復雜性、系統包含的語言、組件的數量、代碼行數、操作系統和庫的使用、以及一些文檔信息。
        若用戶已為應用程序設計一個合理的藍圖,它可能包含書寫文檔時用戶需要的所有信息。如果沒有,用戶可能需要使用一個工具來掃描其應用程序,并生成詳細的體系結構藍圖,以準確地描述系統。該藍圖可更全面的幫助用戶全面了解描述系統。
        構建:了解你正在構建的系統
        一個公司若正在開發項目,這將是軟件風險管理的一個絕佳的機會,當然也是一個挑戰。在這個時候,公司領導對項目如何組合在一起有很大的影響力,其也需要平衡很多因素,例如預算、進度、范圍。
        在設計、部署和構建一個項目時,軟件風險管理的所有方面都發揮了作用:產品管理提供系統需求和客戶的建議;體系結構和安全性為系統構建了框架和防護體系,描述了支撐項目的一般工程框架;系統開發遵循了開發的最佳模式,并進行持續的單元和集成測試,而集成和部署則使用軟件語境分析來對整個系統進行檢查;項目管理和項目發起人與整個團隊合作,便于他們跟進開發過程。
        系統級分析一般出現在前臺,這樣方便項目經理、架構師和安全專家持續監控系統的當前和未來的健康狀況。將系統級分析集成到DevOps管道中,用軟件智能幫助團隊提供提高開發速度并減少返工時間,同時還能確保他們能夠降低最終的系統中的軟件風險。
        為了管理系統的安全風險,開發人員一般需要時刻跟進了解體系結構和開發軟件工程的一些慣例。應用程序的所有者、架構師和安全專家需要一種方法來驗證系統遵循了這些慣例和標準,而系統級分析就滿足了這種要求,還能為開發人員和操作團隊提供實時的反饋,集成工程師、QA、操作、架構和安全專家可以使用系統級的分析來確定安全熱點或缺陷,以便在產品發布之前進行深入的審查。
        開發團隊需要在單元層面上遵循良好的代碼規范來保證系統可靠性和性能效率,但要等系統開始集成,并且能通過質量工程師的系統級分析來進行壓力測試和掃描時,這兩項指標才會有實際的結果。這些測試的輸出需要及時反饋給團隊領導和架構師,以便在最終集成之前改進設計。
        如果代碼剛剛寫完的,開發團隊還在修改代碼,系統可維護成本就會大大降低,并且系統維護也會更加有效。實際應用中,最好同時使用單元級和系統級的分析來努力提高代碼的可讀性,撰寫軟件系統采用的方法和體系結構的文檔,并減少代碼重復。
        轉換:未來的構建目標
        當前,商業現狀,市場和技術變化飛快,管理之前或是當下遇到的軟件風險遠遠不夠,為了在未來的挑戰中能夠存活下來并繼續發展,所有公司及組織需要時刻前進。
        箭在弦上,不得不發。新的技術和增長領域,例如物聯網,塊鏈和認知計算源源不斷地涌現,這些技術組件將在幾年內成為市場主流,企業組織用戶還將面對來自新型市場的激烈競爭壓力和時間上的壓力。需要入駐這些領域,并管理好企業風險。
除了構建軟件風險管理框架之外,企業及組織還需要部署重要的人力資源來了解新技術以優化公司發展戰略,并系統地理清您的舊技術和新技術如何協同工作。 IT領導者現在正在抓住機會實現軟件開發和部署的工業化,從而擴展和自動化現有軟件資產的測試和部署,來推廣即將面世的技術領域的創新資源。
        軟件風險管理工具總覽
        現在我們已經清楚了軟件風險是什么以及如何識別它,讓我們回顧一下可以降低風險的發生率和嚴重性的工具和方法,這些工具和方法在您最有影響力的項目的開發中可能特別適用。我們將在下面的簡短摘要中介紹每個工具,而每個主題下都附有更詳細的解釋。
        產品管理
        產品管理者們一般會羅列并優先處理功能和非功能性要求,這樣開發團隊可以專注于其工作并提供更多的商業價值。一些關乎公司存亡的商業風險其實可以通過仔細規劃公司發展方向來避免,而且在規劃中至關重要的就是什么方向不能發展。產品管理所做的細致的需求分析消除了用戶在使用軟件時遇到的一些問題,并且嚴格規定了軟件系統的一些非功能性要求(包括安全性,隱私性,可靠性,性能效率和可維護性),為軟件系統發布后短期甚至是長期的成功奠定了基礎。
        開發過程
        像敏捷或瀑布這樣的開發方法提供了降低軟件風險因素發生率的方法,還能將問題信息反饋給開發人員。當系統能長時間正常運行時,開發人員就可以構建一個更好的系統,從而不斷降低軟件風險,因為這些較小的穩定??榭梢宰槌篩蟾榷ǖ南低?。
        當下,軟件技術日新月異的變化更加值得注意。企業和組織工程團隊需要制定適當的流程來不斷創新,并使開發人員了解最新的工具和技術。繼續教育和抽出一些時間來讓開發團隊做些創新實驗將越來越重要,這樣才能保持公司在技術和招聘和留人方面的競爭力。
        開發工具
        諸如源代碼管理(SCM)和集成開發環境(IDE)的開發工具具有悠久的歷史,但這些工具最近的版本已經在功能和速度上做了改進,從而提高了開發人員的工作效率,并降低了引入錯誤的風險。它們還與DevOps工具鏈集成,確保交付和部署后依然能向開發人員提供反饋,確保應用程序在部署后也能正常工作,而不僅僅是開發人員的機器上正常運行。
SCM在數百或數千個文件中跟蹤每個修訂版本,允許開發人員進行更改,確定他們可以回滾更改,比較變化,如果有問題,可以與其他開發人員一起更改有沖突的文件。
        IDE將文件管理,編輯,編譯和測試工具捆綁在一起。它們提供了一種類似儀表板的方式,可以將開發人員需要做的所有任務組合在一起,包括諸如FindBugs或SonarQube之類的軟件平臺的集成,這些開發工具能夠提供連續的代碼質量檢測。單位層面的軟件風險在開發人員實例化軟件系統時顯而易見,開發人員可以屆時再進行修改。
        本地代碼分析
        軟件語法分析本著查找重復的,過于復雜的,可讀性差,測試覆蓋不足或違反編碼標準代碼的目的,一般在本地或組件級進行靜態代碼分析(執行而不執行代碼)。現在大多數編程軟件和編譯器都集成了這些類型的工具。軟件語法分析器可以在許多上環境下使用:在IDE進行嵌入式軟件開發時,有一種或多種語言時,以及不同的系統環境下。
        目前已有許多免費和開源工具可用于本地靜態代碼分析,有關的詳細列表請參閱維基百科的靜態代碼分析工具列表。我們將特別提到兩種最常用的工具。
        FindBugs是一種開源的本地代碼分析器。它通過掃描Java代碼來分析其中的可能缺陷,并將潛在錯誤分類為很可怕的,可怕的,令人煩惱的和無關痛癢的四類,從而幫助開發人員了解其可能的嚴重性。
        Sonarqube是一款商業化的句法分析開源工具套件,和IDE中的工具和插件一樣, SonarQube的功能基本上都依賴于一個由商業化的插件組成的大型庫。此外,它還支持多種語言:C、C++、JavaScript、C #,java,COBOL,PL / SQL,PHP,ABAP,這意味著開發者可以在在各種各種的項目中使用它來?;と砑低?,因為SonarQube的廣泛使用,使用包含SonarQube的軟件系統的人也不必再去學習SonarQube。
        盡管如此,當項目在IDE中運行或是跨項目運行時,代碼語法分析僅能一次一次局部地分析組件。它能夠偵測組件自身包含的問題,但它不具備查看系統級問題的權限,也不知道它檢查一個組件時所增加的語境信息。
在某些情況下,額外的語境會讓語法分析器誤報,此時,若開發人員不考慮語境直接對錯誤進行仔細徹底的檢查語法分析,必將會浪費時間和精力。
        您可以將語法代碼分析視為一個儀表板,它能讓開發人員能夠實時查看其正在開發的組件中軟件風險是否產生或是積累。
        全局系統分析
        語法軟件分析的局限性迫使行業向常規的軟件分析中添加了組件依賴關系和數據流這些信息,進而開發出能從整體上認知某個軟件系統的“軟件語境分析”工具。
        上述工具中有一些功能較為復雜,它們使用了語言分析器按組件分解軟件,然后用分解結果來搭建整個系統及其所有組件(代碼和數據庫)和依賴關系的模型。Coverity Architecture Analysis和CAST Application Intelligence Platform(CAST AIP)就是這類工具中兩個突出的例子。 Coverity專注于單一技術,無論是Java的還是C ++的,而CAST可以識別同一系統中不同語言,不同層次中的多種技術。
        一旦軟件語境分析工具構建了系統的模型,它就可以在單元和系統兩個層面上檢查整個系統,而語法分析就只能在單元層面檢查。李祖德(Zude?Li)等人的研究結果表明涉及多個組件間交互的缺陷占所有軟件缺陷的約30%,但卻需要超過80%的修復工作。此外,隨著組件之間相互作用而導致系統的語境不斷變化,軟件語境分析還能避免高頻率的誤報,因為它知道這些誤報是沒有考慮語境,僅對組件進行分析才觸發的。
        系統級分析的潛在缺點是,由于有更大數量級的文件和路徑要檢查,軟件語境分析的運行不能立即完成,所以這種分析通常放在軟件開發生命周期中的系統集成階段運行。即使這樣,更深層次的的分析仍使軟件語境分析在降低軟件風險方面非常有價值。
        管理軟件風險的好處
        在本文中,我們了解了系統地管理軟件風險的方法,研究了將需要調查的問題的種類,知曉了一系列能測量和降低軟件風險的強大工具。這些工具可以幫助企業實現管理軟件風險的產業化,替工程師中做一些可自動化的工作,來讓他們更專注地完成在未來您的公司未來將會用到的一些工作。有了所有這些工具,企業機構便可以提高開發速度,降低出現中斷或安全漏洞的幾率,進而更有力地參與到當下和未來的商業競爭中。
        軟件風險是一種很重要的商務風險。降低軟件風險能直接降低商務風險,包括減少收入損失,提升公司的公眾形象,客戶滿意度和員工滿意度。
                                                                                                    來源:賽迪網