소프트웨어 개발 - 제품 SW 패키징

SW 패키징 : 실행 파일들을 묶어 배포용 설치 파일을 만드는 것

● 사용자 중심  ● 소스코드는 모듈화하여 패키징

● 사용자의 편의성 및 실행 환경을 우선적으로 고려

< 고려사항 >

● 사용자의 시스템 환경  ● SW는 Managed Service 형태로 제공

● UI는 시각적인 자료와 함께 제공, 매뉴얼과 일치시켜 패키징

< 패키징 작업 순서 >

기능 식별 – 모듈화 – 빌드 진행 – 사용자 환경 분석 – 패키징 적용 시험 – 패키징 변경 개선 – 배포

 

릴리즈 노트 : 릴리즈 정보를 SW의 최종 사용자인 고객과 공유하기 위한 문서

● 전체 기능, 서비스 내용, 개선 사항 등을 사용자와 공유  ● SW의 버전 관리, 릴리즈 정보 관리

< 초기 버전 작성 시 고려사항 >

● 현재 시제로 작성  ● 변경/개선된 항목에 대한 이력 정보 작성

< 추가 버전 작성 >

● 중대한 오류가 발생하여 긴급하게 수정하는 경우

● SW에 대한 기능 업그레이드를 완료한 경우

● 사용자로부터 접수된 욕사항에 의해 추가나 수정된 경우

< 작성 순서 >

모듈 식별 – 릴리즈 정보 확인 – 릴리즈 노트 개요 작성 – 영향도 체크 – 정식 릴리즈 노트 작성 – 추가 개선 항목 식별

 

디지털 저작권 관리

● 원본 콘텐츠가 아날로그 시 디지털 변환 후 패키저에 의해 DRM 패키징  ● 크기 작을 시 요청 시점에 패키징

 

관리 및 보호 기술

-> 클리어링 하우스 : 저작권에 대한 사용 권한, 라이선스 발급

-> 패키저 : 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램

-> DRM 컨트롤러 : 배포된 콘텐츠의 이용 권한 통제

-> 보안 컨트롤러 : 콘텐츠 원본을 안전하게 유통

 

SW 설치 매뉴얼 : 개발 초기부터 적용된 기준, 사용자가 SW를 설치하는 과정에 필요한 내용을 기록한 설명서

● 사용자 기준으로 작성  ● 설치 시작부터 완료할 때까지 과정을 빠짐없이 순서대로 설명

● 오류 메시지 및 예외 상황에 관한 내용을 별도로 분류하여 설명

 

SW 사용자 매뉴얼 : 사용자가 SW를 사용하는 과정에서 필요한 내용을 문서로 기록

● SW 사용에 필요한 절차, 환경 등 제반 사항이 모두 포함

● 오류에 대한 패치나 기능에 대한 업그레이드를 위해 매뉴얼의 버전 관리

● 컴포넌트 단위로 매뉴얼 작성

 

형상 관리 : SW의 변경 사항을 관리

● SW 개발의 전 단계에 적용되는 활동

● SW 개발 전체 비용을 줄임, 방해 요인이 최소화

< 중요성 >

● 변경 사항을 체계적으로 추적하고 통제  ● 무절제한 변경 방지

● 버그나 수정 사항 추적

● SW는 가시성이 결핍되므로 진행 정도를 확인하기 위한 기준으로 사용

-> 가시성 : 대상을 확인할 수 있는 정도

< 기능 >

● 형상 식별 : 형상 관리 대상에 이름과 관리 번호 부여

● 버전 제어 : SW 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리

● 형상 통제 : 변경 요구를 검토, 현재의 기준선이 잘 반영될 수 있도록 조정

● 형상 감사 : 기준선의 무결성 평가

● 형상 기록 : 형상의 식별, 통제, 감사 작업의 결과를 기록/관리

< 주요 용어 >

● 저장소( Repository ) : 정보들이 저장된 곳

● 가져오기( Import ) : 버전 관리가 되지 않는 아무것도 없는 저장소에 처음으로 파일 복사

● 체크아웃( Check-Out ) : 저장소에서 파일 받아옴

● 체크인( Check-In ) : 저장소의 파일을 새로운 버전으로 갱신

● 커밋 : 이전에 갱신된 내용이 있는 경우 충돌을 알리고 diff 도구를 이용해 수정 후 갱신 완료

-> diff 도구 : 비교 대상이 되는 파일의 내용을 비교하여 다른 부분을 찾아 표시

< 등록 과정 >

가져오기 – 체크아웃 – 커밋 – 동기화( Update ) – Diff

 

공유 폴더 방식

● 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사

● 담당자는 공유 폴더의 파일을 자기 PC로 복사 후 컴파일하여 이상 유무 확인

-> 오류 확인 : 해당 파일 등록한 개발자에게 수정 의뢰

-> 오류 없음 : 각 개발자들이 동작 여부 다시 확인

● 변경 사항 DB에 기록하여 관리

● SCCS, RCS, PVCS, QVCS

 

클라이언트/서버 방식 : 버전 관리 자료가 중앙 시스템( 서버 )에 저장되어 관리

● 서버의 자료를 개발자별로 자신의 PC로 복사하여 작업 후 변경된 내용을 서버에 반영

● 모든 버전 관리는 서버에서 수행  ● 하나의 파일을 서로 다른 개발자가 작업 시 경고 메시지 출력

● CVS, SVN

 

분산 저장소 방식 : 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리

● 원격 저장소 자료를 자신의 로컬 저장소로 복사 후 작업, 변경된 내용을 로컬 저장소에 우선 반영 후 원격 저장소에 반영

● 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용하여 작업 가능

● Git, GNU arch, DCVS

 

Subversion( SVN )

● CVS 개선  ● 클라이언트/서버 구조

● 모든 개발 작업은 trunk 디렉터리에서 수행, 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어 작업 완료 후 trunk 디렉터리와 병행

● 커밋할 때마다 리비전이 1씩 증가  ● 클라이언트는 대부분의 OS에서 사용, 서버는 유닉스를 사용

< 주요 명령어 >

● add : 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록

● commit : 클라이언트의 소스 파일을 서버의 소스 파일에 적용

● checkout : 소스파일을 서버에서 클라이언트로 받아온다.

● import : 아무것도 없는 서버의 저장소에 맨 처음 소스 파일 저장

● export : 순수한 소스 파일만 서버에서 받아온다.

● merge : 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병행

 

Git

● 2개의 저장소

- 로컬( 지역 ) 저장소 : 실제 개발 진행하는 장소, 버전 관리 수행

- 원격 저장소 : 여러 사람들이 협업을 위해 버전을 공동 관리

● 원격 저장소나 네트워크에 문제가 있어도 로컬 저장소에서 작업 가능

● 브랜치 이용 : 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅 가능

● 파일의 변화를 스냅샷으로 저장

< 주요 명령어 >

● branch : 새로운 브랜치 생성, -d옵션으로 삭제 가능

● merge : 지정한 브랜치의 변경 내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영함으로써 두 브랜치 병합

● push : 로컬 저장소의 변경 내역을 원격 저장소에 반영

● fork : 지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제

 

빌드 자동화 도구

● 지속적인 통합 개발 환경에서 유용

 

Jenkins

● JAVA 기반의 오픈 소스 형태  ● 서블릿 컨테이너에서 실행

● 대부분의 형상 관리 도구와 연동 가능  ● 분산 빌드나 테스트 가능

 

Gradle

● Groovy 기반의 오픈 소스 형태

● 플러그인을 설정하면 안드로이드 뿐만 아니라 JAVA, C/C++ 등의 언어에서 빌드 가능

● DSL을 스크립트 언어로 사용  ● 태스크 단위로 실행