軟體智能

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

相關層面

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

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

組成

軟體智能有以下的組成內容：

• 程式碼分析器，可以識別程式語言產生的物件、開源軟體產生的外部物件、第三方物件、框架、應用程式介面（API）或是服務（英语：Service (systems architecture)），作為其他軟體智能分析的資訊基礎。
• 軟體產品或是應用程式內在架構的圖形視覺化，以及相關藍圖^[7]，其中包括相依性，從資料取得（自動化實時的資料擷取，或是終端用戶輸入）到資料的儲存、軟體中不同的層次^[8]、以及各元件之間的耦合。
• 在元件和影響分析特徵之間瀏覽及切換的能力
• 軟體缺陷列表，在架構或是程式撰寫上違反標準最佳實務的部份^[9]，防範不正常的資料調用，避免影響軟體的安全性及整合性^[10]。
• 軟體結構及软件质量的評級或評分，對應標準可能是工業標準，像是OMG、IT軟體品質協會（英语：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]，提昇品質及生產力
• 軟體開發安全（英语：Software development security）以及其恢復力（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）.