hi there

소프트웨어 패키징

개요: 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것

- 모듈의 개수 = 기능의 개수

패키징은 철저히 사용자 중심으로 진행

고려사항: OS, CPU, 메모리, 최소환경, 매뉴얼, 고객 편의

패키징 작업 순서
- 보통 2~4주 내에서 지정, 주기가 끝날 때마다 패키징 수행
- 기능 식별 -> 모듈화 -> 빌드 진행 -> 사용자 환경 분석 -> 패키징 및 적용 시험 -> 패키징 변경 개선 -> 배포

디지털 저작권 관리(DRM)

저작권: 저작물에 대해 저작자가 가지는 배타적 독점적 권리
DRM: 저작권자가 배포한 디절털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록 디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 결쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술.

DRM의 구성

클리어링하우스: 라이센스 관리, 발급, 결제 관리
패키저: 컨텐츠를 메타 데이터와 함께 배포 가능한 형태로 묵어 암호화하는 프로그램
DRM 컨트롤러: 배포된 컨텐츠의 이용 권한을 통제하는 프로그램
보안 컨테이너: 컨텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치

소프트웨어 버전 등록

소프트웨어 패키징의 형상 관리: 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동

형상관리의 특징: 관리/추적 가능, 개발의 진행정도 확인, 오류 및 변경 방지 -> 비용 감소, 오류 최소화

버전 관리 도구

공유 폴더 방식
클라이언트/서버 방식(SVN)
분산 저장소 방식(Git): Local에서 버전관리를 할 수 있기 때문에, Local 선 반영 후 이를 원격 저장소에 반영함.

빌드 자동화 도구

Jenkins

JAVA 기반의 오픈 소스 형태
SVN, Git 등 대부분의 형상 관리 도구와 연동 가능
Web GUI 제공, 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트 가능 Gradle
Groovy 기반의 오픈 소스 형태의 자동화 도구
안드로이드, JAVA, C/C++ 등의 언어도 빌드 가능
Groovy를 사용하여 만든 DSL(Domain Specific Language)을 스크립트 언어로 사용
실행할 처리 명령들을 모아 태스크로 만든 후 태스크 단위로 실행

어플리케이션 테스트

왜 테스트를 할까?

잠재적 결함이나 고객의 요구사항을 만족시켜 신뢰도를 높일 수 있기 때문이다.

테스트의 기본 원리

완벽한 소프트웨어 테스팅은 불가능하다.
파레토 법칙(80%의 오류는 20%의 모듈에서 발생)에 따르기도 한다.
살충제 역설 현상 보완: 테스트 케이스를 지속적으로 보완 및 개선
오류 부재의 궤변: 오류가 없어도 사용자의 요구사항을 만족시키지 못하면 품질이 높다고 할 수 없다.

테스트 분류

프로그램 실행 여부에 따른 테스트

정적 테스트: 명세서나 소스 코드를 대상으로 분석
동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트

테스트 기반

명세 기반 테스트: 요구사항에 대한 명세를 테스트케이스로 만들어 테스트
구조 가반 테스트: SW 내부의 논리 흐름에 때라 테스트 케이스를 작성 후 테스트
경험 기반 테스트: 테스트 경험을 기반으로 수행하는 테스트(명세 불충분, 시간이 부족할 때 사용)

시각에 따른 테스트
검증 테스트: 의도한 기능이 완성됐는지
확인 테스트: 요구한대로 제품이 완성됐는지

목적에 따른 테스트

회복(잘 복귀 되는지)
안전(보호가 잘 이루어지는지)
강도(과부하 시에도 잘 실행되는지)
성능(응답 시간, 처리량)
구조(복잡도 여부 테스트)
회귀(수정된 코드에 새로운 결함이 있는지)
병행(변경 소프트웨어와 기존 소프트웨어에 동일한 입력을 주어 결과 비교)

개발 단계에 따른 어플리케이션 테스트

단위(모듈) 테스트:
- 소프트웨어를 구현한 뒤 가장 먼저 진행되는 테스트
- 구조 기반(White box), 명세 기반(black box) 테스트로 진행
통합 테스트:
- 모듈 간의 상호작용 오류를 검사
- 비점진적 방식(한번에 통합)과 점진적 방식(단계적 통합)이 있음
  - 점진적 방식은 하향식 통합 테스트의 깊이 우선 통합과 너비 우선 통합이 존재한다

시스템 테스트:
- 기능적 요구사항(black box test), 비기능적 요구사항(White box test)으로 구분하여 만족하는 지 테스트
인수 테스트:
- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
- 개발한 소프트웨어를 사용자가 직접 테스트한다.

어플리케이션 테스트 프로세스

1) 테스트 계획: 시스템 구조 파악, 테스트 비용 산정, 시작 및 종료 조건 정의 2) 설계(분석 및 디자인): 사용자의 요구사항 분석, 리스크 분석 및 우선순위 결정
3) 시나리오 작성: 테스트용 스크립트 작성 4) 테스트 수행: 테스트의 실행 결과를 측정하여 기록 5) 결과 평가 및 리포팅 6) 결함 추적 및 관리

테스트 자동화 도구

장점) 자원 소모 감소, 품질 보장, 일관적 단점) 교육 및 학습을 위한 자원이 필요, 상용 도구의 경우 추가 비용 필요

결함 관리

결함 관리 프로세스
계획 -> 기록 -> 검토 -> 수정 -> 재확인 -> 보고서 작성

결함 추적 순서
등록 -> 검토 -> 할당 -> 수정 -> 보류 -> 종료 -> 해제

결함의 분류

시스템 결함: 어플리케이션 및 DB의 결함
기능 결함: 프로세스와 결과 등이 불일치
GUI 결함: 화면의 특정 정보에 대한 표시 오류
문서 결함: 문서, 매뉴얼의 불일치와 의사소통이 원활하지 않아 발생된 결함

2과목: 요약 정리(2) - 제품 소프트웨어 패키징