소프트웨어 인텔리전스

Software intelligence

소프트웨어 인텔리전스는 정보 기술 환경에서 복잡한 소프트웨어 시스템을 보다 잘 이해하고 제어하기 위해 데이터베이스 구조, 소프트웨어 프레임워크, 소스 코드를 분석하기 위해 설계된 소프트웨어에 의해 생산된 소프트웨어 자산의 구조적 상태에 대한 통찰력이다.[1]BI(비즈니스 인텔리전스)와 마찬가지로 소프트웨어 인텔리전스는 데이터 및 소프트웨어 내부 구조를 채굴하기 위한 소프트웨어 도구와 기법에 의해 생산된다.최종 결과는 비즈니스 및 소프트웨어 이해관계자가 정보에 입각한 의사결정을 내리고,[citation needed] 소프트웨어 개발 조직의 효율성을 측정하며, 소프트웨어 상태에 대해 소통하고, 소프트웨어 대재앙을 방지하기 위해 사용하는 정보다.[2]

역사

소프트웨어 인텔리전스는 1979년 미국 엔지니어, 기업가, 컨설턴트, 소프트웨어 인텔리전스 주식회사의 설립자인 커크 폴 라플러는 소프트웨어 인텔리전스 코퍼레이션의 설립자다.당시엔 주로 SAS활동과 있었는데 1979년부터전문가로 활동해왔다 관련이.[3]

1980년대 초, 빅터 R.바실리는 소프트웨어 엔지니어링, 소프트웨어 개발 평가 및 변형에 관한 유효한 소프트웨어 엔지니어링 데이터를 수집하는 방법을 상세히 기술하는 여러 논문들에 참여했다.[4] [5] 2004년에 소프트웨어 분석에서 서로 다른 소프트웨어 공급업체들은 제품명과 마케팅 전략의 일부로 이 용어를 사용하기 시작한다.그리고 2010년에는 아흐메드 E.Hassan과 Tao Xie는 소프트웨어 인텔리전스를 "소프트웨어 실무자들이 매일 의사 결정 프로세스를 지원할 수 있도록 최신의 적절한 정보를 제공하는 관행"으로 정의했으며 소프트웨어 인텔리전스는 소프트웨어 시스템의 수명 동안 의사 결정 프로세스를 지원해야 한다.그들은 앞으로 수십 년 동안 소프트웨어 인텔리전스를 "현대 소프트웨어 실무에 대한 강력한 영향"으로 정의함으로써 계속된다.[6]

역량

소프트웨어에 내재된 복잡하고 광범위한 구성 요소와 주제 때문에 소프트웨어 인텔리전스는 소프트웨어의 다른 측면으로부터 파생된다.

  • 소프트웨어 구성은 소프트웨어 애플리케이션 구성 요소의 구성이다.[7]소프트웨어 코딩 및 외부 구성 요소로부터의 소스 코드 통합으로 구성 요소:오픈 소스, 타사 구성 요소 또는 프레임워크.라이브러리나 서비스에 대한 애플리케이션 프로그래밍 인터페이스 호출을 사용하여 다른 구성요소를 통합할 수 있다.
  • 소프트웨어 아키텍처는 그 가운데 시스템, 관계, 재산의 요소의 구조와 구성을 말한다.
  • 소프트웨어 결함은 보안, 안정성, 복원력 및 예기치 못한 결과를 초래할 수 있는 문제를 지정한다.소프트웨어 결함에 대한 표준 정의는 없지만 가장 많이 받아들여지는 것은 공통 결함을 공통 취약점 열거로 분류하는 MITRE Corporation의 것이다.[8]
  • 소프트웨어 등급은 소프트웨어의 속성을 평가한다.역사적으로 속성의 분류와 용어는 ISO 9126-3과 후속 ISO 25000:2005[9] 품질 모델에서 파생되었다.
  • 소프트웨어경제학은 의사결정을 내리고 통치하기 위해 과거, 현재 또는 미래의 소프트웨어를 자원평가하는 것을 말한다.[10]

구성 요소들

소프트웨어 인텔리전스 플랫폼의 기능은 점점 더 많은 수의 구성요소를 포함한다.

  • 프로그래밍 언어, 오픈 소스에서 생성된 외부 개체, 타사 개체, 프레임워크, API 또는 서비스에 의해 생성된 개체를 식별하는 다른 소프트웨어 인텔리전스 구성 요소의 정보 기반 역할을 하는 코드 분석기
  • 데이터 수집(자동화 및 실시간 데이터 캡처, 최종 사용자 입력)부터 데이터 스토리지, 소프트웨어 내의 서로 다른 계층[12] 및 모든 요소 간의 결합에 이르기까지 종속성을 포함하는 것으로[11] 간주되는 소프트웨어 제품 또는 애플리케이션의 내부 구조를 그래픽으로 시각화하고 Blueprint 작성.
  • 구성 요소 내 탐색 기능 및 영향 분석 기능
  • 표준화된 모범 사례,[13] 클라우드 환경으로의 마이그레이션을 막는 클라우드 차단기,[14] 소프트웨어의 보안 및 무결성을 수반하는 악성 데이터 호출에 대한 결함, 아키텍처 및 코드 위반 목록
  • 클라우드 또는 기타 시스템에 대한 신뢰성, 보안, 효율성, 유지관리성 및 확장성을 평가하는 OMG, CISQ 또는 SEI와 같은 업계 표준에 부합하는 구조 및 소프트웨어 품질의 등급 또는 점수.
  • 작업, 크기 조정 및 기술 부채를[16] 포함한 소프트웨어 경제성을 수량화하고 추정하는 메트릭
  • 분석 결과 및 산업 표준 간의 비교를 가능하게 하는 산업 참조 및 벤치마킹

사용자 측면

기업에서 소프트웨어 인텔리전스 시스템의 사용을 성공적으로 통합하기 위해서는 몇 가지 고려가 이루어져야 한다.궁극적으로 소프트웨어 인텔리전스 시스템이 조직에 가치를 더하기 위해서는 사용자가 이를 받아들이고 활용해야 한다.시스템이 사용자의 임무에 가치를 더하지 않으면 M에서 명시한 대로 사용하지 않을 뿐이다.2003년의 스토리.[17]

코드 수준과 시스템 표현에서 소프트웨어 인텔리전스 시스템은 설계, 설명 및 문서화를 위한 추상적 견해와 소프트웨어 시스템을 이해하고 분석하기 위한 상세한 견해 등 다른 수준의 추상적 관점을 제공해야 한다.[18]

거버넌스 수준에서 소프트웨어 인텔리전스에 대한 사용자 수용은 시스템의 출력뿐만 아니라 시스템의 내부 기능과 관련된 다른 영역을 포함한다.이 규정에는 다음과 같은 요구사항이 포함된다.

  • 포괄적: 정보가 누락되면 사용자가 시스템을 수용하는 데 영향을 미치는 요인일 뿐만 아니라 잘못되거나 부적절한 결정을 초래할 수 있다.[19]
  • 정확성: 정확성은 공정하고 명백한 의견과 판단을 보장하기 위해 데이터를 수집하는 방법에 따라 달라진다.[20]
  • 정밀도: 정밀도는 보통 동일하거나 다른 선원의 여러 측정값을 비교하여 판단한다.[21]
  • 확장성: 소프트웨어 산업의 확장성의 부족은 실패로 이어지는 중요한 요인이다.[22]
  • 신뢰할 수 있음: 결과를 신뢰할 수 있고 믿을 수 있어야 함.
  • 구축 가능 및 사용 가능.

적용들

소프트웨어 인텔리전스는 그것이 전문가용 소프트웨어든, 개인용 소프트웨어든, 임베디드 소프트웨어든, 소프트웨어 환경과 관련된 모든 사업에 많은 응용프로그램을 가지고 있다.연결 및 구성요소의 사용에 따라 애플리케이션은 다음과 관련된다.

  • 변경 및 현대화: 모든 내부 구성 요소에 대한 통일된 문서 및 청사진, 외부 코드 통합 또는 소프트웨어[23] 내부 또는 외부 구성 요소 호출
  • 복원력 및 보안:[24] IT 환경의 구조적 결함을 진단하기 위한 업계 표준에 대한 측정보안, 특정 규정 또는 기술적 문제에 대한 컴플라이언스 검증.
  • 의사 결정 및 거버넌스: 소프트웨어 자체 또는 소프트웨어 개발에 관련된 이해관계자에 대한 분석 제공(예:[25] 비즈니스 및 IT 리더에게 비즈니스 목표를 향한 진척 상황을 알리기 위한 생산성 측정)비즈니스 및 IT 리더가 소프트웨어에 대해 정보에 입각한 사실 기반의 결정을 내릴 [26]수 있도록 지원하는 평가 및 벤치마킹

마켓플레이스

소프트웨어 인텔리전스는 고도의 규율이며, 위에서 열거한 응용 프로그램을 대상으로 점차 성장해 왔다.이에 대한 필요성을 주도하는 시장은 다음과 같다.

  • 엔터프라이즈 성능[27][28] 향상을 위한 APA(애플리케이션 포트폴리오 분석)
  • 소프트웨어 KPI[29] 생산 및 품질 및 생산성 향상을 위한 소프트웨어 평가
  • 소프트웨어 보안 및 복원력 측정 및 검증
  • 소프트웨어 진화 또는 기존 현대화, 소프트웨어 시스템의 청사진화가 필요하거나 도구를 개선 및 용이하게 하는 도구

참조

  1. ^ Dąbrowski R. (2012) 건축 창고 및 소프트웨어 인텔리전스에 관하여.인: Kim T, Lee Y, Fang W. (eds) 미래 세대 정보 기술.FGIT 2012.컴퓨터 과학 강의 노트, 7709.베를린 하이델베르크 스프링거
  2. ^ 아흐메드 E.하산과 타오 시.2010. 소프트웨어 인텔리전스: 소프트웨어 엔지니어링 데이터의 미래.FSE/SDP 워크샵의 미래 소프트웨어 엔지니어링 연구(FoSER '10)에서ACM, 뉴욕, 뉴욕, 미국, 161–166
  3. ^ "Mr. Kirk Paul Lafler". 21 December 2015.
  4. ^ Basili, Victor R. (1981). Data collection, validation and analysis. Software Metrics: An Analysis and Evaluation (PDF). MIT Press. p. 143. ISBN 0-262-16083-8.
  5. ^ Basili, Victor R.; Weiss, David M. (Nov 1984). A Methodology for Collecting Valid Software Engineering Data. IEEE Trans. Softw. Eng. 10, 6 (November 1984). pp. 728–738. doi:10.1109/TSE.1984.5010301. hdl:1903/7513.
  6. ^ 아흐메드 E.하산과 타오 시.2010. 소프트웨어 인텔리전스: 소프트웨어 엔지니어링 데이터의 미래.FSE/SDP 워크샵의 미래 소프트웨어 엔지니어링 연구(FoSER '10)에서ACM, 뉴욕, 뉴욕, 미국, 161–166. doi:10.1145/1882362.1882397
  7. ^ 니어스트라스츠, 오스카, 테오 더크 메이글러."소프트웨어 구성의 방향 연구."ACM 컴퓨팅 설문 조사 27.2(1995): 262-264 doi:10.1145/210376.210389
  8. ^ 카나시로, L 등"정적 분석 데이터를 기반으로 복잡성이 낮은 모델에서 소프트웨어 결함 예측"정보 시스템 엔지니어링 및 관리 저널 3.2(2018): 17 doi:10.20897/jisem.201817
  9. ^ "ISO 25000:2005" (PDF). Archived (PDF) from the original on 2013-04-14. Retrieved 2013-10-18.
  10. ^ Boemm, Barry W, Kevin J. Sullivan."소프트웨어 경제: 로드맵."소프트웨어 엔지니어링의 미래에 관한 회의의 진행.2000. doi:10.1145/336512.336584
  11. ^ Renato Novais, José Amancio Santos, Manoel Mendonsa, 소프트웨어 진화 분석을 위한 다중 시각화 전략의 조합을 실험적으로 평가한 결과, Journal of Systems and Software, 2017, 페이지 56–71, ISSN 0164-12, doi:10.1016/jss 2017.03.006.
  12. ^ 롤리아, 제롬 A, 케네스 C.셉시크."계층 방법." 소프트웨어 엔지니어링 21.8,1995,689-700,doi:10.1109/32.403785의 IEEE 거래
  13. ^ 코드 품질에 대한 소프트웨어 엔지니어링 규칙.http://it-cisq.org/standards/code-quality-standards/
  14. ^ 발랄리, 아르민, 압바스 헤이다노리, 푸얀 잠시디."마이크로 서비스 아키텍처로 devops 지원:클라우드 네이티브 아키텍처로의 마이그레이션."IEEE 소프트웨어 33.3 , 2016년 5월–6월, 42-52,doi:10.1109/MS.2016.64
  15. ^ 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.
  16. ^ R. 하스, R. 니더마이어, E.저겐스, "팀스케일:기술 부채 문제 해결 및 소프트웨어 품질 관리," 2019 IEEE/ACM 기술 부채 국제 회의(TechDebt), 몬트리올, QC, 캐나다, 2019, 55-56, doi:10.1109/TechDebt.119.00016.
  17. ^ Storey MA. (2003) 인지 프레임워크를 사용한 소프트웨어 탐색 도구 설계.인: Zhang K. (eds) 소프트웨어 시각화.Springer International Series in Engineer and Computer Science, vol 734.캘리포니아 주 보스턴의 스프링거
  18. ^ 이선아, 강성원, 그래픽 코드 추천자 사용 시 개발자에게 어떤 상황 정보가 도움이 되는가?, 시스템 및 소프트웨어 저널, 117권, 2016년, 페이지 199–217, ISSN 0164-1212, doi:10.1016/jss2016/j.jss2016.02.050.
  19. ^ 린다 G. 월리스, 스티븐 D.시트즈, 소프트웨어 조치의 채택: A 기술 수용 모델(TAM) 관점, 정보 & 관리, 제51권, 이슈 2, 2014 페이지 249–259, ISSN 0378-16, doi:10.1016/j.im.12.003
  20. ^ 리퍼트, S.K. & Forman, H. (2005)정보 기술의 활용: 입양 후 행동의 인지적 요인 및 경험적 요인 검토.IEEE 엔지니어링 관리 거래, 52, 363–381.
  21. ^ 라지브 D.뱅커와 크리스 F.케머러(1992년).정보 시스템 개발을 위한 성능 평가 지표: 주체-에이전트 모델.정보 시스템 연구, 3, 4, 379–400권.
  22. ^ M. Crowne "소프트웨어 제품 스타트업이 실패하는 이유, 어떻게 해야 하는가.스타트업 기업에서의 소프트웨어 제품 개발의 진화," IEEE 국제 엔지니어링 관리 회의, 2002, 페이지 338–343 vol.1. doi:10.1109/IEMC. 2002.1038454
  23. ^ 파르나스, 데이비드 로지, 정확한 문서:더 나은 소프트웨어의 열쇠, 소프트웨어 엔지니어링의 미래, 2011, 125–148, doi:10.1007/978-3-642-15187-3_8
  24. ^ "Data and Digital Platform".
  25. ^ LaValle S, Less E, Shockley R, Hopkins MS 및 Kruschwitz N(2011) 빅 데이터, 분석 및 통찰력에서 가치로의 경로.MIT Sloan Management Review 52(2), 21–32.
  26. ^ 제인츠 프라스니카르와 지가 데벨작과Allesh Ahchan(2005) 전략적 관리의 도구로서의 벤치마킹, Total Quality Management & Business Excellence, 16권, 2, 257–275, doi:10.1080/14783360500054400
  27. ^ "Definition of Applications Portfolio Analysis (APA) - Gartner Information Technology Glossary".
  28. ^ "Effective Strategies to Deliver Sustainable Cost Optimization in Application Services".
  29. ^ "About the Automated Function Points Specification Version 1.0".