소프트웨어 개발

퀵정렬

디지털 저작권 관리(DRM) 구성요소
- 콘텐츠 제공자: 콘텐츠를 제공하는 저작권자
- 콘텐츠 분배자: 암호화된 콘텐츠 제공
- 패키저: 콘텐츠를 메타 데이터와 함께 배포 가능한 단위로 묶는 기능
- 보안 컨테이너: 원본을 안전하게 유통하기 위한 전자적 보안장치
- DRM 컨트롤러: 배포된 콘텐츠의 이용 권한을 통제
- 클리어링 하우스: 소비자와 유통업자 사이에 발생하는 거래에 대해 디지털 저작권 라이선싱을 중개하고 라이선스 발급을 수행하는 장소

검증 -> 개발자
확인 -> 사용자

해싱함수에는
제산법, 제곱법, 중첩법(폴딩법), 숫자분석법, 기수 변환법, 무작위 방법이 있다.

소프트웨어 품질 목표

1. 이식성 portabilityh
   다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 능력
2. 효율성 efficiency
   최소의 작업으로 요구되는 기능을 수행하는 정도
3. 사용 용이성 usability
   소프트웨어를 쉽게 사용할 수 있는 정도
4. 정확성 correctness
   사용자의 요구사항을 충족시키는 정도

트리 운행법
- Preorder 운행 : Root -> Left -> Right 
- Inorder 운행 : Left -> Root -> Right
- Postorder 운행 : Left -> Right -> Root

알고리즘 시간 복잡도
비례하지 않는(항상 일정한) O(1)
로그에 비례하는 O(log2^n)
정비례하는(선형) O(n)
로그*변수에 비례하는(선형 로그) O(nlog2^n)
제곱에 비례하는 O(n^2)
세제곱에 비례하는 O(n^3)
지수 비례하는 O(2^n)
팩토리얼에 비례하는 O(n!)

클린 코드 작성 원칙

1. 가독성
   누구든지 쉽게 읽을 수 있게 작성, 쉬운 용어를 사용 or 들여쓰기 딱
2. 단순성
   코드를 간단하게 작성, 한 번에 한 가지를 처리하도록 코드 작성 클래스/메소드/함수 최소 단위 분리
3. 의존성 배제
   다른 모듈에 영향 안 미치게 딱
4. 중복성 최소화
   중복 최소화 하시고 중복된건 공통화
5. 추상화
   상위에서는 간략하게 앱의 특성을 나타내고, 상세 내용은 하우에 구현

스키마

1. 외부 스키마
   개인 또는 응용 개발자 입장에서 보는 데이터베이스
2. 개념 스키마
   모든 응용 프로그램 또는 사용자들이 필요로 하는 조직 전체 데이터베이스로 단 하나만 존재한다.
3. 내부 스키마
   물지적 저장장치 입장에서 보는 데이터베이스

법칙

1. pareto
   오류의 80%는 전체의 20%내에서 발견된다
2. brooks
   지연되는 프로젝트에 인력을 투입하면 더 늦어진다.
3. boehm
   ?
4. jackson
   ?

소스코드 품질분석 도구

1. 정적
   1. pmd
      소스 코드에 대한 미사용 변수 최적화안된 코드 등 결함을 유발할 수 있는 코드 검사
   2. cppcheck
      C/C++ 코드에 대한 메모리 누수 오버플로우 등 분석
      SonarQube : 중복 코드 복잡도 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼
   3. checkstyle
      자바 코드에 대해 소스코드 표준을 따르고 있는지 검사한다.
   4. ccm
      다양한 언어의 코드 복잡도를 분석한다.
   5. cobertura
      자바 언어의 소스코드 복잡도 분석 및 테스트 커버리지 측정
2. 동적
   1. Avalanche
      Valgrind 프레임워크 및 STP기반 / 프로그램 결함 및 취약점 분석
   2. valgrind
      프로그램 내에 존재하는 메모리 및 쓰레드 결함 분석

형상 관리 절차

1. 식별
   대상을 구분하고 번호를 정의하고 부여
2. 통제
   변경 제안을 검토, 현재 소프트웨어 기준선에 반영하도록 통제
3. 감사
   항목의 변경이 계획에 따라 제대로 이루어졌는지를 검토/승인
4. 기록/보고
   소프트웨어 개발 상태에 대한 보고서를 제공하는 것

알고리즘

1. 선택정렬 : O(n^2)
   선택정렬은 가장 작은 값을 찾아 첫번째 값과 교환합니다.
2. 삽입정렬 : O(n^2)
3. 버블정렬 : O(n^2)
   1이랑 2랑, 2랑 3이랑, 쭉~ 끝까지가 PASS 1
4. 합병정렬 : O(Nlog2N)
5. 힙정렬 : O(Nlog2N)
6. 이진탐색
   (처음값+끝값)/2를 비교해 찾으면 회수 포함 X

단위 테스트
스텁(stub) 하향식
드라이버(driver) 상향식
 - 테스트 슈트 - 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
 - 테스트 스텁 - 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈
 - 테스트 케이스 - 사용자의 요구사항을 정확히 준수했는지 확인하기 위한 입력 값, 실행조건, 기대결과 등으로 만들어진 테스트 항목의 명세서
 - 테스트 오라클 - 테스트 케이스 실행이 통과됐는지 실패했는지 판단하기 위한 기준

소프트웨어 공학에서 워크스루(Walkthrough)
 - 단순한 테스트 케이스를 이용하여 프로덕트를 수작업으로 수행해 보는 것이다.
 - 사용사례를 확장하여 명세하거나 설계 다이어그램, 원시코드, 테스트 케이스 등에 적용할 수 있다.
 - 복잡한 알고리즘 또는 반복, 실시간 동작, 병행 처리와 같은 기능이나 동작을 이해하려고 할 때 유용하다.

워크스루: 요구사항 명세서 작성자를 포함하여 사전 검토한 후에 짧은 검토 회의를 통해 결함을 발견
인스펙션: 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견.
 - 프로그램 수행 대신 읽어보고 눈으로 확인
 - 코드 품질 향상 기법
 - 동적 정적 모두 사용
- 결함과 함께 코딩 표준 준수 여부, 효율성 등 다른 이슈 검사하기도 함

인터페이스 구현 검증도구
 - xUnit : Java, C++ 등 다양한 언어 지원하는 단위 테스트 프레임워크
 - STAF : 서비스 호출 및 컴포넌트 재사용 등 환경 지원하는 테스트 프레임워크
 - FitNesse : 웹 기반 테스트케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임워크
 - Selenium : 다양한 브라우저 및 개발 언어 지원하는 웹 애플리케이션 테스트 프레임워크
 - Watir : Ruby를 사용하는 애플리케이션 테스트 프레임워크
 - Ruby : 인터프리터 방식의 객체지향 스크립트 언어
 - NTAF : FitNesse의 장점인 협업 기능과  STAF의 장점인 재사용 및 확장성을 통합한 네이버의 테스트 자동화 프레임워크이다.

블랙박스 테스트 유형
소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법.
 - 동치(동등) 분할 검사(Equivalence Partitioning Testing)
 - 경계값 분석(Boundary Value Analysis)
 - 원인-효과 그래프 검사(Cause-Effect Graphing Testing)
 - 오류 예측 검사(Error Guessing)
 - 비교 검사(Comparison Testing)

화이트박스 테스트 유형
소프트웨어 혹은 제품의 내부 구조, 동작을 세밀하게 검사하는 테스트 방식으로, 외부에서 요구사항에 따른 예상 결과값을 테스트 하는 것과는 다르게 내부 소스 코드를 테스트하는 기법으로 사용자가 들여다 볼 수 없는 구간의 코드 단위를 테스트 한다.
 - 기초 경로 검사
 - 제어 구조 검사
    - 조건 검사(Condition Testing)
    - 루프 검사(Loop Testing)
    - 데이터 흐름 검사(Data Flow Testing)

반정규화(Denormalization) 유형
반정규화 공부하다 집중이 부진
(집)계 테이블 추가 - sum,avg 등의 계산 미리 수행
(중)복 테이블 추가 - 서버 분리 또는 업무 구별
(이)력 테이블 추가 - 레코드 중복 저장
(부)분 테이블 추가 - 접근 시도가 많은 자료만 모아두기
(진)행 테이블 추가 - A에 접근하기위해 다수의 테이블을 거칠 경우 간소화
특정 부분만을 포함하는 테이블의 추가

소프트웨어 형상 관리(Software Configuration Management)
: 소프트웨어의 변경 사항을 체계적으로 추적하고 통제하는 것(단순 버전 관리보다 더 포괄적인 개념)

형상 관리 절차: 형상 식별 -> 형상 통제 -> 형상 감사 -> 형상 기록/보고

형상 식별
- 형상 관리의 대상들을 구분하고 관리 목록의 번호를 정의하여 부여하는 과정
- 형상 관리 대상: 품질관리 계획서, 품질관리 매뉴얼, 요구 사항 명세서, 설계/인터페이스 명세서, 테스트 설계서, 소스코드

형상 통제
- 소프트웨어 형상 변경 제안을 검토, 현재 소프트웨어 기준선(Baseline)에 반영하도록 통제
- 형상 통제가 이루어지기 위해서는 형상 통제 위원회(Configuration Control Board, CCB)의 승인을 통한 변경 통제가 이루어짐

형상 감사
- 형상 항목의 변경이 계획에 따라 제대로 이뤄졌는지를 검토/승인하는 것
- 개발자, 유지보수 담당자가 아닌 제 3자의 객관적인 확인 및 검증 과정을 통해 새로운 형상의 무결성을 확보하는 활동

형상 기록/보고
- 소프트웨어 개발 상태에 대한 보고서를 제공하는 것
- 베이스라인 산출물에 대한 변경과 처리 과정에서의 변경을 상태 보고에 모두 기록