跳至內容

軟件智能

維基百科,自由的百科全書

軟件智能是對軟件資產內部結構狀態的瞭解,是透過專用軟件來分析數據庫結構、軟件框架原始碼後的產物,目的是瞭解並管理複雜的軟件系統[1]。軟件智能和商業智能(BI)類似,都是用數據挖掘及探究軟件內部架構的軟件工具及相關技術所產生。分析結果可以用在商業上,提供給和軟件有關的人士,以便進行決策、討論軟件的健康情形、量度軟件開發組織的效率,並且預防大型的軟件災難[2]

相關層面

[編輯]

軟件元件及主題既有複雜性,範圍又很廣,軟件智能和以下的軟件層面有關:

  • 軟件組成是指建構軟件應用元件的過程[3]。元件是從撰寫軟件程式碼而來,也包括整合程式碼以及外部元件:開源程式、第三方元件或是框架。其他的元件可能是由應用程式接口呼叫函式庫或是服務而來。
  • 軟件架構是指系統各元件的結構及組織、彼此之間關係、以及元件的性質。
  • 軟件缺陷是指會造成安全性、穩定性、恢復性相關問題的錯誤,或是會產生非預期結果的錯誤。有關軟件缺陷,還沒有一個標準的定義,不過最多人接受的定義是來自非營利組織MITRE英語Mitre Corporation的定義,其中會用通用缺陷列表將軟件缺陷進行分類[4]
  • 軟件等級是評估軟件的屬性。以往的分類以及詞語是源自ISO/IEC 9126以及後續的ISO 25000:2005[5]品質模型。
  • 軟件經濟學是指過去、現在及未來有關軟件開發需要資源的評估,目的是為了決策以及管理[6]

組成

[編輯]

軟件智能有以下的組成內容:

  • 程式碼分析器,可以識別程式語言產生的物件、開源軟件產生的外部物件、第三方物件、框架應用程式介面(API)或是服務英語Service (systems architecture),作為其他軟件智能分析的資訊基礎。
  • 軟件產品或是應用程式內在架構的圖形視覺化,以及相關藍圖[7],其中包括相依性,從資料取得(自動化實時的資料擷取,或是終端用戶輸入)到資料的儲存、軟件中不同的層次[8]、以及各元件之間的耦合
  • 在元件和影響分析特徵之間瀏覽及切換的能力
  • 軟件缺陷列表,在架構或是程式撰寫上違反標準最佳實務的部份[9],防範不正常的資料調用,避免影響軟件的安全性及整合性[10]
  • 軟件結構及軟件質量的評級或評分,對應標準可能是工業標準,像是OMGIT軟件品質協會英語CISQ(CISQ)或軟件工程學院英語Software Engineering Institute(SEI),會針對軟件可靠度、安全性、效率、可維護性、是否可以擴展到雲端或是其他系統等。
  • 量化及評估軟件經濟學(包括工作量、程式大小及技術負債)的度量[11]
  • 產業參考以及基準測試,可以在產業標準及各分析的輸出上比較。

使用者的層面

[編輯]

若希望軟件智能系統順利的在企業內導入,就需要有使用者相關的考量。最終的目的是軟件智能系統可以被使用者接受,在日常作業中應用,為組織加值。若系統無法完成使用者的任務,依照M. Storey在2003年所述的,使用者就不會使用此一系統了[12]

在程式碼以及系統呈現的層面上,軟件智能系統需要可以提供不同程度的抽象化:為了瞭解並且分析軟件系統,在設計、解釋、文件化上都需要抽象的觀點,也需要另一個詳細的觀點[13]

在管理的層面上,客戶對軟件智能的接受度和系統的內在功能有關,也和系統的輸出有關。包括了以下的需求:

  • 全面:缺少資訊有可能讓管理者作出錯誤或是不適當的決策,這也是影響系統接受度的因素之一[14]
  • 準確:準確性和資料的搜集方式有關,以確保公正以及沒有爭議的意見以及判斷[15]
  • 精確:精確可以透過針對同一來源(或不同來源)多次量測來判斷[16]
  • 可擴展性:在軟件產業中,缺乏可擴展性往往是導致失敗的關鍵因素之一[17]
  • 可信:結果必須讓人可以信賴。
  • 可以布署,並且可用。

應用

[編輯]

軟件智能已應用在許多和軟件環境有關的企業中,可能是針對專業軟件、個人用軟件或是嵌入式軟件。 依照元件的用途以及企業應用的原因,軟件智能可能和以下事務有關:

  • 軟件更改以及現代化:可以針對所有內部元件、外部整合的程式、對內部或外在元件的呼叫產生一致性的文件,以及軟件的藍圖[18]
  • 軟件復原性及安全性:針對產業標準進行度量,並且診斷IT環境下的結構性缺陷[19]。並且確認有關安全性、特殊法及技術要求的相容性。
  • 決策及治理:提供有關軟件的分析,可能和組織本身,或是和軟件開發有關的人士

。軟件智能可以量測軟件開發的生產力,和企業目標之間的差距,相關資料可以給企業以及IT部門的主管[20]。評估以及基準測試可以幫助企業以及IT部門主管針對軟件進行正式、以事實為基礎的決策[21]

行銷觀點

[編輯]

軟件智能已逐漸的用在上述的應用中。以下是行銷層面需要此一技術的原因:

  • 應用軟件組合分析(Application Portfolio Analysis、APA):目的在提昇企業的效能[22][23]
  • 軟件評估,以產生軟件的KPI[24],提昇品質及生產力
  • 軟件開發安全以及其恢復力(resiliency)的評估及確認
  • 軟件演進或是舊軟件的現代化,需要軟件系統的藍圖,或是工具提昇、機能修改之類的議題

參考資料

[編輯]
  1. ^ Dąbrowski R. (2012) On Architecture Warehouses and Software Intelligence. In: Kim T., Lee Y., Fang W. (eds) Future Generation Information Technology. FGIT 2012. Lecture Notes in Computer Science, vol 7709. Springer, Berlin, Heidelberg
  2. ^ Ahmed E. Hassan and Tao Xie. 2010. Software intelligence: the future of mining software engineering data. In Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER '10). ACM, New York, NY, USA, 161–166
  3. ^ Nierstrasz, Oscar, and Theo Dirk Meijler. "Research directions in software composition." ACM Computing Surveys 27.2 (1995): 262-264 doi:10.1145/210376.210389
  4. ^ Kanashiro, L., et al. "Predicting software flaws with low complexity models based on static analysis data." Journal of Information Systems Engineering & Management 3.2 (2018): 17 doi:10.20897/jisem.201817
  5. ^ ISO 25000:2005 (PDF). [2013-10-18]. (原始內容存檔 (PDF)於2013-04-14). 
  6. ^ Boehm, Barry W., and Kevin J. Sullivan. "Software economics: a roadmap." Proceedings of the conference on The future of Software engineering. 2000. doi:10.1145/336512.336584
  7. ^ Renato Novais, José Amancio Santos, Manoel Mendonça, Experimentally assessing the combination of multiple visualization strategies for software evolution analysis, Journal of Systems and Software, Volume 128, 2017, pp. 56–71, ISSN 0164-1212, doi:10.1016/j.jss.2017.03.006.
  8. ^ Rolia, Jerome A., and Kenneth C. Sevcik. "The method of layers." IEEE transactions on software engineering 21.8,1995, 689-700,doi:10.1109/32.403785
  9. ^ Software Engineering Rules on code quality. http://it-cisq.org/standards/code-quality-standards/頁面存檔備份,存於互聯網檔案館
  10. ^ Q. Feng, R. Kazman, Y. Cai, R. Mo and L. Xiao, "Towards an Architecture-Centric Approach to Security Analysis," 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), Venice, 2016, pp. 221-230, doi:10.1109/WICSA.2016.41.
  11. ^ R. Haas, R. Niedermayr and E. Juergens, "Teamscale: Tackle Technical Debt and Control the Quality of Your Software," 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), Montreal, QC, Canada, 2019, pp. 55-56, doi:10.1109/TechDebt.2019.00016.
  12. ^ Storey MA. (2003) Designing a Software Exploration Tool Using a Cognitive Framework. In: Zhang K. (eds) Software Visualization. The Springer International Series in Engineering and Computer Science, vol 734. Springer, Boston, MA.
  13. ^ Seonah Lee, Sungwon Kang, What situational information would help developers when using a graphical code recommender?, Journal of Systems and Software, Volume 117, 2016, pp. 199–217, ISSN 0164-1212, doi:10.1016/j.jss.2016.02.050.
  14. ^ Linda G. Wallace, Steven D. Sheetz, The adoption of software measures: A technology acceptance model (TAM) perspective, Information & Management, Volume 51, Issue 2, 2014, pp. 249–259, ISSN 0378-7206, doi:10.1016/j.im.2013.12.003
  15. ^ Lippert, S.K., & Forman, H. (2005). Utilization of information technology: examining cognitive and experiential factors of post-adoption behavior. IEEE Transactions on Engineering Management, 52, 363–381.
  16. ^ Rajiv D. Banker and Chris F. Kemerer (1992). Performance Evaluation Metrics for Information Systems Development: A Principal-Agent Model. Information Systems Research, volume 3, number 4, 379–400.
  17. ^ M. Crowne, "Why software product startups fail and what to do about it. Evolution of software product development in startup companies," IEEE International Engineering Management Conference, 2002, pp. 338–343 vol.1. doi:10.1109/IEMC.2002.1038454
  18. ^ Parnas, David Lorge, Precise Documentation: The Key to Better Software, The Future of Software Engineering, 2011, 125–148, doi:10.1007/978-3-642-15187-3_8
  19. ^ 存档副本. [2020-08-12]. (原始內容存檔於2018-06-15). 
  20. ^ LaValle S, Lesser E, Shockley R, Hopkins MS and Kruschwitz N (2011) Big data, analytics and the path from insights to value. MIT Sloan Management Review 52 (2), 21–32.
  21. ^ Janez Prašnikar, Žiga Debeljak,Aleš Ahčan (2005) Benchmarking as a tool of strategic management, Total Quality Management & Business Excellence, volume 16, number 2, 257–275, doi:10.1080/14783360500054400
  22. ^ 存档副本. [2020-08-12]. (原始內容存檔於2018-06-15). 
  23. ^ 存档副本. [2020-08-12]. (原始內容存檔於2018-11-30). 
  24. ^ 存档副本. [2020-08-12]. (原始內容存檔於2021-02-28).