OSS Tools

# Where to Search OSS project?

  - Wikipedia, codeProject,SourceForge,Github, GitLab,BitBucket.....등의 다양한 오픈소스 제공 웹사이트가 존재한다.

  - Black Duck Open Hub : 오픈소스 소프트웨어 아카이빙에 최적화된 사이트. 다양한 오픈소스 다운로드 가능

 

 # Scanning OSS Component

  - Scanning OSS (FOSS) : license 관련해서 주석 정보들을 counting해준다.

  : software안에 잠재적인 문제가 발생할 수 있는 오픈소스가 있는지 스캔하는 툴이다.  (라이센스 문제..)

 - OSS로 인해 법적 분쟁이 발생할 수도 있어 license를 준수하는 것은 상당히 중요하다.

 

  - Identifying OSS Vulnerabilities : OSS내의 취약점이 존재하는지 분석해주며, 이는 취약점 db에 기반한다.

 

# SW Development Tools

  - 현존하는 가장 좋은 툴과 조합을 찾아내서 개발을 해야 한다.

  - 표준화된 개발 툴과 configuration(set-up)을 사용해서 엔지니어들에게 전달한다.

  - 언제든 미래에 재구성하여 사용할수 있도록 해야 한다.  disk image등을 만들어 다운받아 놓던가, 절대경로 매크로등을 사용한다.  ( GCC= /user/bin/gcc 이런식으로 사용함)

  - 명시적으로 문서화를 해야 한다.

-> 이 모든 것의 궁극적 목표는 퀄리티와 효율성을 높이는 것이다.

 

 

# Error Propagation

 -> 이는 소프트웨어 품질관리에서 상당히 중요한 내용이다.

 : 에러들은 나머지 프로그램에 전파되어 영향을 끼칠 수도 있다. 하나의 에러를 통해서 더 큰 문제가 발생할 수도 있다. 

=> 따라서 그 전에 버그를 미리 찾아야 개발/유지 비용을 조금이라도 줄일 수 있다. 

 - 따라서 디버깅을 빨리하는 것은 상당히 중요하다.

버그는 전파력이 매우 높음...

 

 - 에러를 늦게 찾을수록 개발 보수 비용이 드라마틱하게 증가한다. 디버깅/관련된 재작업에 걸리는 시간은 소프트웨어 개발 총 시간의 절반이상을 차지한다.

 

# Lint 

 -> 코드 분석, 에러, 경고, 코드 효율을 높이는 제안 등을 돕는 도구이다.

 -> compiler/interpreter보다 더 철저하게 검사한다 : 인터프리터가 찾지 못한 오류를 추가적으로 찾을 수 있으며, 매 컴파일/코딩단계에서 사용하기보단 여유가 있을 때 사용.

  EX)  Pylint, flake8

 

# Code Review

 -> 권장하는 작업으로, 메인 작업은 아니다. 

 : 다양한 사용자가 contribute하여 코드를 체크하고 테스트한다면 소프트웨어 퀄리티가 보장이 된다. (peer review 적극적 활용)

 - 사용 툴 : Gerrit, GitHub

 - 목표 : 에러를 찾아 취약점 패치, 퀄리티 증대

 

# Issue Tracking System

 - 이슈 리스트/ 각 이슈의 due date를 tracking한다.

 - 각 툴로 감지한 이슈들을 모두 tracking한다.

  1) Compiler / Interpreter : Syntax Error

  2) Lint : 더 빡센 오류 감지

  3) Code Review : 논리적인 오류 ( Correctness 혹은 peformance issue)

  4) Unit Test : Mostly Runtime/Logical Error

  5) Integration test : 다른 모듈과 통합했을 때 발생하는 에러들 (Deadlock, race condition, Interface mismatch..)

  6) third Party test : eg. with DBMS

 

 

# Integration Frequency - Phased or Incremental?

 : 얼마나 자주 다른 모듈과 통합을 하는지는 핵심적인 문제이다.

 

 1) Phased Integration

  : 모든 component가 한번에 통합되는 방식이며, 모든 SW를 한꺼번에 디버깅/테스트한다

 -> 이는 모든 문제가 한번에 몰아서 발생될 수 있다.

  : 테스트가 덜 된 클래스, 두 클래스간의 인터페이스 호환 에러, 두 클래스간 소통 에러..등등이 발생할 수 있다.

 

 => 이를 MERGE HELL, INTEGRATION HELL 이라고도 부른다.

 

 2) Incremental Integragtion

 : 한 번에 하나의 파일씩 통합해나간다. -> 뼈대를 만들고 점점 붙여나가는 방식을 사용한다. 뼈대와 새로운 클래스를 붙일때마다 테스트와 디버깅을 진행한다

 

- 장점 : 어떤 파일이 추가됐을 때 에러가 발생하면 근본 원인/fault를 찾기 쉬우며, 각 unit들이 시스템의 조각으로써 테스팅되며 진행상황을 전체적으로 모니터링이 가능하다. 

 -> Snowballing integration이라고도 할 수 있다. ( 눈덩이 불어나듯)

 

  # Incremental Integation Strategies

 - 각 모듈들을 누구부터 점진적으로 통합할지에 대한 이슈가 발생한다.

  1) Sandwith Integration : High level-> low level-> middle-level classes

  2) Risk-oriented Integration

 : 위험도 수준으로 분류해서 가장 어려운거 먼저 개발하고, 쉬운건 나중에 개발한다.

  3) Fetaure-oriented Integration

 : 기능별로 분화해서 각 기능마다 통합한다.

 

-> 위의 전략들 중 뭐가 효율적인지는 프로그램마다 다르다~ 

 

# Daily Build and Smoke Test

 1) Daily build

  : 매일 combine/Integration을 진행한다. -> 부지런히 통합하는게 중요함

   2) Smoke Test

  :  프로그램의 중요한 기능들이 잘 돌아가는지 확인하기 위해(ascertain) 전체적인 소프트웨어 빌드 후에 실행한다.

 -> 프로그램의 주요 기능들이 잘 동작하는지, product smokes가 발생하는지 확인한다.

 

  3) Benefits of Daily Build and Smoke Test

 : 항상 프로그램을 좋은 상태로 유지하며, 계속 수면위로 드러나지 않는 문제가 있는지 지속적으로 테스팅하게 된다.

 

# Continuous Integration

 : 하루에 몇번이건 통합해나가는 과정 ( repository에 새로운 commit이 push될때마다)

 - 이는 Continuous Integration Tool을 사용해서 이루어진다 => Travis CI, Jenkins등의 툴 이용.

 : 다른 기기까지의 범위에서 프로그램을 빌드하고 자동으로 테스트 하고, 테스트 결과를 사용자에게 notice 알림해주는 기능도 존재한다.

 

# Version Control Program

  : 프로그램을 개발할때마다 새로운 버전이 발생하고, 새로운 버전을 지속적으로 업데이트 해둬야 할 필요성이 있다.

 - Version Control Program 의 핵심 기능은 file등에 대해서 수정된 내용/version을 tracking하는 것이다.

 => 이를 통해서 특정 시점에서 어떤 부분을 수정했는지, 다수의 이용자들 사이에서 발생하는 코드 변화와 수정 버전들 등 모든 변경내용에 대한 정보를 확인할 수 있다. 이를 통해 이전 시점으로 돌아가 recovery할 수 있는 기능도 존재한다.

 

- The Lock-modify-Unlock Model : 이 모델에서는 repository가 오직 한 명만이 파일에 접하여 수정할 수 있다.

- The Copy-modify-Merge Model : user들은 copy 버전을 이용해 각자 동시에 작업/수정하며, 각 private copy들은 이후에 merge되어 final version을 만들게 된다.