정처기 소프트웨어 개발 - 2.3 제품 소프트웨어 패키징

<소프트웨어 패키징> ☆★★★


(1) 소프트웨어 패키징의 개요
- 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것
- 사용자 중심 (개발자 중심x)
- 소스코드는 향후 관리를 고려하여 모듈화하여 패키징
- 사용자가 소프트웨어를 사용하게 될 환경을 이해하여, 다양한 환경에서 소프트웨어를 손쉽게 사용할 수 있도록
   일반적인 배포 형태로 패키징 함
- 사용자의 편의성 및 실행 환경을 우선적으로 고려해야 한다.

(2) 패키징 시 고려사항
- 사용자의 시스템 환경, 운영체제, CPU, 메모리 등에 필요한 최소 환경을 정의함
- UI는 사용자가 눈으로 직접 확인할 수 있도록 시각적인 자료와 함께 제공하고 메뉴얼과 일치시켜 패키징 함
- 소프트웨어는 패키징 + 하드웨어와 함께 관리될 수 있도록  Managed Service 형태로 제공하는 것이 좋음
- 고객의 편의성을 고려한 안정적인 배포가 중요함
- 다양한 사용자의 요구사항을 반영할 수 있도록 패키징의 변경 및 개선에 대한 관리를 항상 고려

(3) 패키징 작업 순서
- 소프트웨어 개발 기법에 따라 달라짐
- 에자일 기법 : 짧은 개발 주기 반복, 2 ~ 4주 내에서 지정, 각 주기가 끝날때마다 패키징 수행
- 주기별로 패키징한 결과물은 테스트 서버에 배포함
- 최종 패키징한 결과물은 고객이 사용할 수 있도록 온라인, 오프라인으로 배포
- 온라인 배포
     : 별도로 마련한 운영 서버에 설치 및 사용 메뉴얼과 함께 배포 파일을 등록, 고객이 직접 다운받아 사용하도록 함
- 오프라인 배포
     : CD-ROM이나 DVD, USB 등에 설치 및 사용 메뉴얼과 함께 배포 파일을 담음
- 1. 기능 식별
     : 작성된 코드의 기능 확인
- 2. 모듈화
     : 확인된 기능 단위로 코드를 분류함
- 3. 빌드 진행
     : 모듈 단위별로 실행 파일을 만듦
- 4. 사용자 환경 분석
     : 소프트웨어가 사용될 환경이나 운영체제, CPU, RAM등의 최소 운영 환경을 정의함
- 5. 패키징 및 적용 시험
     : 빌드된 실행 파일들을 정의된 환경에 맞게 배포용 파일 형식으로 패키징함
       정의된 환경과 동일한 환경에서 패키징 결과를 테스팅한 후 소프트웨어에 대한 불편사항을 사용자 입장에서 확인
- 6. 패키징 변경 사항
     : 확인된 불편 사항을 반영하기 위한 패키징의 변경 및 개선을 진행함
- 7. 배포 
     : 배포 수행 시 오류가 발생하면 해당 개발자에게 전달하여 수정을 요청함

---

<릴리즈 노트 작성> ☆★★★

(1) 릴리즈 노트(Release Note)의 개요
- 개발 과정에서 정리된 리리즈 정보를 소프트웨어의 최종 사용자인 고객과 공유하기 위한 문서
- 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부 확인 가능
- 소프트웨어에 포함된전체 기능, 서비스 내용, 개선 사항 들을 사용자와 공유할 수 있음
- 소프트웨어의 버전관리나 릴리즈 정보를 체계적으로 관리할 수 있음
- 소프트웨어 초기 배포 시, 출시 후 개선 사항을 적용한 후 추가 배포 시에 제공함
- 소프트웨어 초기 배포시 제공되는 것은 소프트웨어에 포함된 기능, 사용환경에 대한 내용 확인 가능
- 소프트웨어 출시 후 개선된 작업이 있을 때마다 관련 내용을 담아 제공
- 정리된 정보들은 철저한 테스트를 거친 것
- 개발팀에서 제공하는 소프트웨어 사양에 대한 최종 승인을 얻은 후 문서화 되어 제공함

(2) 릴리즈 노트 초기 버전 작성 시 고려사항
- 정확하고 안전한 정보를 기반으로 개발팀에서 직접 현재시제로 작성해야 함
- 이력이 정확하게 관리되어 변경, 개선된 항목에 대한 이력 정보들도 작성되어야 함
- 작성 표준 형식은 없지만 일반적으로 Header(머릿말), 개요, 목적, 문제 요약, 제현 항목,
  수정/개선 사항, 사용자 영향도, SW 지원 영향도, 노트, 면책 조항, 연락처 항목이 포함됨 

(3) 릴리즈 노트 추가 버전 작성 시 고려사항
- 테스트 과정에서 베타 버전이 출시되거나 특수한 상황이 발생하는 경우 릴리즈 노트를 추가로 작성함
- 중대한 오류가 발생, 긴급하게 수정하는 경우
     : 릴리즈 버전을 출시하고, 버그 번호를 포함한 모든 수정 내용을 담아 릴리즈 노트를 작성함
- 소프트웨어에 대한 기능 업그레이드를 완료한 경우
     : 릴리즈 버전을 출시하고, 릴리즈 노트를 작성함
- 사용자로부터 접수된 요구사항에 의해 추가, 수정된 경우
     : 자체 기능 향상과는 다른 별도의 릴리즈 버전으로 출시, 릴리즈 노트 작성

(4) 릴리즈 노트 작성 순서
- 1. 모듈 식별
     : 모듈별 빌드 수행 후 릴리즈 노트에 작성될 내용들 확인
- 2. 릴리즈 정보 확인
     : 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 노트 날짜, 노트 버전 등을 확인
- 3. 릴리즈 노트 개요 작성
     : 소프트웨어 및 변경사항 전체에 대한 간략한 내용을 작성함
- 4. 영향도 체크
     : 버그나 이슈 관련 내용, 해당 릴리즈 버전에서의 기능 변화가 다른 소프트웨어나
       기능을 사용하는데 미칠 수 있는 영향에 대해 기술함
- 5. 정식 릴리즈 노트 작성
     : Header(머릿말), 개요, 영향도 체크 항목을 포함하여 정식 릴리즈 노트에 작성될 기본 사항들을 작성함
- 6. 추가 개선 항목 식별
     : 추가 버전 릴리즈 노트 작성이 필요한 경우 추가 릴리즈 노트를 작성함

---

<디지털 저작권 관리(DRM)> ★★★★

(1) 저작권의 개요
- 저작물에 대하여 창작자가 가지는 배타적 독립적 권리로 타인의 침해를 받지 않을 고유한 권한
- 저작권 보호 기술
     : 컴퓨터 프로그램들과 같이 복제하기 쉬운 저작물에 대하 불법 복제 및 배포 등을 막기 위한 기술적인 방법을 통칭

(2) 디지털 저작권 관리(DRM; Digital Right Managemet)의 개요
- 저작권자가 배포한 디지털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록
  디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 걸쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술
- 원본 콘텐츠가 아날로그인 경우
     : 디지털로 변환 후 패키저(Packager)에 의해 DRM 패키징 수행
- 콘텐츠의 크기가 小 경우
     : 사용자가 콘텐츠를 요청하는 시점에서 실시간으로 패키징을 수행
- 콘텐츠의 크기가 大 경우
     : 미리 패키징을 수행 한 후 배포
- 종량제 방식을 적용한 소프트웨어의 경우
     : 클리어링 하우스를 통해 서비스의 실제 사용량을 측정하여 이용한 만큼의 요금을 부과함
- 패키징을 수행하면 콘텐츠에는 암호화된 저작권자의 전자서명이 포함,
  저작권자가 설정한 라이선스 정보가 클리어링 하우스(Clearing House)에 등록됨
- 사용자가 콘텐츠를 사용하기 위해서는 클리어링 하우스에 등록된 라이선스 정보를 통해
  사용자 인증과 콘텐츠 사용 소유 여부를 확인받아야 함

(3) 디지털 저작권 관리의 흐름도
- 클리어링 하우스(Clearing House)
     : 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리 등을 수행하는 곳
- 콘텐츠 제공(Contents Provider)
     : 콘텐츠를 제공하는 저작권자
- 패키저(Packager)
     : 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램
- 콘텐츠 분배지(Contents Distributor)
     : 암호화된 콘텐츠를 유통하는 곳이나 사람
- 콘텐츠 소비자(Contents Distributor)
     : 콘텐츠를 구매해서 사용하는 주체
- DRM 컨트롤러(DRM Contoroller)
     : 배포된 콘텐츠의 이용 권한을 통제하는 프로그램
- 보안 컨테이너(Security Container)
     : 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치

(4) 디지털 저작권 관리의 기술 요소
- 암호화(Encryption)
     : 콘텐츠 및 라이선스 암호하고, 전자서명을 할 수 있는 기술
- 키 관리(Key Management)
     : 콘텐츠를 암호화한 키에 대한 저장 및 분배 기술
- 암호화 파일 생성(Packager)
     : 콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술
- 식별 기술(Identification)
     : 콘텐츠에 대한 식별 체계 포현 기술
- 저작권 표현(Right Expression)
     : 라이선스의 내용 표현 기술
- 정책 관리(Policy Management) 
     : 라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술
- 크랙 방지(Tamper Resistance)
     : 크랙에 의한 콘텐츠 사용 방지 기술
- 인증(Authentification)
     : 라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술

---

<소프트웨어 버전 등록> ☆★★★

(1) 소프트웨어 패키징의 형상 관리
- 형상관리(SCM; Software Configuration Management)
     : 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
- 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보
- 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지 보수 단계에서도 수행됨
- 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 함

(2) 형상 관리의 중요성
- 지속적인 소프트웨어의 변경 사항을 체계적으로 추적하고 통제 가능
- 제품 소프트웨어에 대한 무절제한 변경 방지 가능
- 제품 소프트웨어에서 발견된 버그나 수정 사항을 추적할 수 잇음
- 소프트웨어는 형태가 없어 가시성이 결핍 --> 진행 정도를 확인하기 위한 기준으로 사용될 수 있음

(3) 형상 관리 기능
- 형상 식별
     : 형상 관리 대상에 이름과 관리 번호를 부여, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이해지도록 하는 작업
- 버전 제어
     : 소프트웨어 업그레이드, 유지보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 
       이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업
- 형상 통제(변경 관리)
     : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(Base Line)이 잘 반영되도록 조정하는 작업
- 형상 기록(상태 보고)
     : 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업

(4) 소프트웨어의 버전 등로 관련 주요 용어
- 저장소(Repository)
     : 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
- 가져오기(Import)
     : 버전 관리가 되어있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사함
- 체크아웃(Check-Out)
     : 프로그램을 수정하기 위해 저장소에서 파일을 받음
      소스 파일과 함께 버전 관리를 위한 파일들도 받아옴
- 체크인(Check-In)
     : 체크아웃 한 파일의 수정을 완료한 후 저장소의 파일을 새로운 버전으로 갱신함
- 커밋(Commit)
     : 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우, 충돌을 알리고 diff도구를 이용해 수정한 후 갱신을 완료함
- 동기화(Update)
     : 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화 함

(5) 소프트웨어 버전 등록 과정
- 1. 가져오기(Import)
     : 개발자가 저장소에 신규로 파일을 추가함
- 2. 인출(Check-Out)
     : 수정 작업을 진행할 개발자가 저장소에 추가된 파일을 자신의 작업공간으로 인출함
- 3. 예치(Commit)
     : 인출한 파일을 수정한 후 설명을 붙여 저장소에 예치함
- 4. 동기화(Update)
     : 커밋 후 새로운 개발자가 자신의 작업 공간을 동기화함, 이때 기존 개발자가 추가했던 파일이 전달됨
- 5. 차이(Diff)
     : 새로운 개발자가 추가된 파일의 수정 기록을 확인, 이전 개발자가 추가한 파일과 이후 변경된 파일의 차이를 확인

---

 

<소프트웨어 버전 관리 도구> ★★★★

(1) 공유 폴더 방식
- 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
- 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사함
- 담당자는 공유 폴더의 파일을 자기 PC로 복사 후, 컴파일하여 이상 유무 확인
- 이상 유무 확인 과정에서 파일의 오류가 확인 --> 해당 파일을 등록한 개발자에게 수정을 의뢰
- 파일에 이상이 없다면 다음날 각 개발자들이 동작 여부를 다시 확인
- 파일을 잘못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해 파일의 변경 사항을 데이터베이스에 기록하여 관리
- SCCS, RCS, PVCS, QVCS 

(2) 클라언트/서버 방식
- 버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식
- 서버의 자료를 개발자별로 자신의 PC(클라언트)로 복사하여 작업한 후 변경된 내용을 서버에 반영함
- 모든 버전 관리는 서버에서 수행
- 하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지 출력
- 서버에 문제가 발생 --> 서버가 복구되기 전까지 다른 개발자와의 협업 및 버전 관리 작업 중단됨
- CVS, SVN(Subversion), CVSNT, Clear Case, Perforce

(3) 분산 저장소 방식
- 버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식
- 개발자별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사하여 작업한 후
  변경된 내용을 로컬 저장소에서 우선 반영(버전 관리)한 다음 이를 원격 저장소에 반영함
- 로컬 저장소에서 버전 관리가 가능하므로 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용하여 작업 가능
- Git, GNU arch, DCVS, Bazzar, Mercurial, TeamWare, Bitkeeper, Plastic SCM

(4) Subversion(서브버전, SVN)
- CVS를 개선한 것
- 클라이언트/서버 구조로, 서버에는 최신 버전의 파일들과 변경 내역이 관리됨
- 모든 개발 작업은 trunk 디렉토리에 수행되며, 추가 작업은 branches 디렉토리 안에 별도의 디렉토리를 만들어
  작업을 완료한 후 trunk 디렉토리와 병합함 
- 커밋할 때마다 리버전(Reversion)이 1씩 증가함
- 클라이너트는 대부분의 운영체제에서 사용되지만, 서버는 주로 유닉스를 사용함
- 소스가 오픈되어있어 무료로 사용가능
- 파일이나 디렉토리의 이름 변경, 이동 등이 가능
- add, commit, update, checkout, lock/unlock, import, export, into, diff, merge 명령어 사용

(5) Git(깃)
- 리누스 토발스(Linus Tovalds)가 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후
  주니어 하마노(Junio Hamano)에 의해 유지 보수 되고 있음
- 분산 관리 시스템으로 지역(로컬) 저장소와 원격 저장소, 즉 2개의 저장소가 존재함
- 지역 저장소
     : 개발자들이 실제 개발을 진행하는 장소로, 버전 관리가 수행됨
       --> 버전 관리가 신속하게 처리됨, 원격 저장소나 네트워크에 문제가 있어도 작업 가능
- 원격 저장소
     : 여러사람들이 협업을 위해 버전을 공동 관리하는 곳
       자신의 버전 관리 내역을 반영, 다른 개발자의 변경 내용을 가져올 때 사용
 - 브랜치를 이용하면 기본 버전 관리 틀에 영향 x, 다양한 형태의 기능 테스팅이 가능
- 파일의 변화를 스냅샷(Snapshot)으로 저장, 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름을 파악 가능
- add, commit, branch, checkout, merge, init, remote add, push, fetch, clone, fork 명령어 사용

---

<빌드 자동화 도구> ☆★★★

(1) 빌드 자동화 도구의 개념
- 빌드
     : 소스코드 파일을 컴파일 한 후 여러개의 모듈을 묶어 실행 파일로 만드는 과정
- 빌드 자동화 도구
     : 빌드를 포함하어 테스트 및 배포를 자동화하는 도구
- 에자일 환경에서는 하나의 작업이 마무리될 때마다 모듈 단위로 나눠서 개발된 코드들이 지속적으로 통합되는데
  이러한 지속적인 통합 개발 환경에서 빌드 자동화 도구는 유용하게 활용됨
- Ant, Make, Maven, Gradle, Jenkins

(2) Jenkins
- JAVA 기반의 오픈 소스 형태, 가장 많이 사용되는 빌드 자동화 도구
- 서블릿 컨테이너에서 실행되는 서버 기반 도구
- SVN, Git 등 대부분의 형상 관리 도구와 연동이 가능
- 친숙한 Web GUI 제공으로 사용이 쉬움
- 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트가 가능

(3) Gradle
- Groovy를 기반으로 한 오픈소스 형태의 자동화 도구, 안드로이드 앱 개발 환경에서 사용됨
- 안드로이드, 플러그인을 설정하면 JAVA, C/C++, Python 등의 언어도 빌드가 가능함
- Groovy를 통해 만든 DSL(Domain Speific Language)을 스크립트 언어로 사용함
- 실행할 처리 명령어들을 모아 태스크(Task)로 만든 후 태스크 단위로 실행함
- 이전에 사용했던 태스크를 재사용하거나 다른 시스템의 태스크를 고용할 수 있는 빌드 캐시 기능을 지원하므로
  빌드의 속도를 향상시킬 수 있음

 

www.yes24.com/Product/Goods/82838724?OzSrank=6

2020 시나공 정보처리기사 필기

* 2020 시나공 정보처리기사 필기 요약한 내용입니다.