3장 - 제품 소프트웨어 패키징 | 섹션13. 소프트웨어 사용자 매뉴얼 작성, 섹션14. 소프트웨어 버전 등록, 섹션15.소프트웨어 버전 관리 도구, 섹션16. 빌드 자동화 도구

2024년도 시나공 필기 책 내용 정리 

---

섹션 13. 소프트웨어 사용자 매뉴얼 작성

 

1. 소프트웨어 사용자 매뉴얼의 개요

 

• 사용자가 소프트웨어를 사용하는 과정에서 필요한 내용을 문서로 기록한 설명서와 안내서
• 사용자가 소프트웨어 사용에 필요한 정차, 환경 등의 제반 사항이 모두 포함되도록 작성
• 소프트웨어 배포 후 발생될 수 있는 오류에 대한 패치나 기능에 대한 업그레이드를 위해 매뉴얼의 버전을 관리
• 개별적으로 동작이 가능한 컴포넌트 단위로 매뉴얼을 작성
• 컴포넌트 명세서와 컴포넌트 구현설계서를 토대로 작성
• 목차 및 개요, 서문, 기본, 기본 사항 등이 기본적으로 포함 되어있어야 함
• 목차에는 매뉴얼 전체 내용을 순서대로 요약한 후 관련 내용의 시작 페이지를 함께 기술
• 개요에는 소프트웨어의 주요 특징, 매뉴얼의 구성과 실행 방법, 사용법, 항목별 점검 기준, 항목별 설정 방법 등에 대한 내용을 기술

---

2. 서문

 

• 문서이력, 사용자 매뉴얼의 주석, 기록 보관을 위한 필요한 내용을 기술
• 문서이력은 설치 매뉴얼의 구조와 차이가 없음
• 사용자 매뉴얼의 주석
  
  • 주의사항 : 소프트웨어를 사용할 때 사용자가 반드시 알고 있어야 하는 중요한 내용을 기술
  • 참고사항 : 특별한 사용자의 환경이나 상횡에 대한 내용을 기술
• 기록 보관 내용
  
  
  • 소프트웨어를 사용하면서 필요한 기술 지원이나 추가 정보를 얻기 위한 소프트웨어 등록 정보를 기술
  • 소프트웨어 등록 시 필요한 정보는 소프트웨어 명칭, 모델명, 문서번호, 제품번호, 구입 날짜 등임

---

3. 기본 사항

항목	설명
소프트웨어 개요	소프트웨어의 주요 기능 및 UI 설명 UI 및 화면 상의 버튼, 프레임 등을 그림으로 설명
소프트웨어 사용 환경	소프트웨어 사용을 위한 최소 환경 설명 CPU, 메모리 등의 사양, 운영체제 버전 설명 최초 구동에 대한 설명 소프트웨어 사용 시 발생할 수 있는 프로그램 충돌이나 개인정보, 보안 등에 관한 주의사항을 설명
소프트웨어 관리	소프트웨어의 사용 종료 및 관리 등에 관한 내용 설명
모델, 버전별 특징	모델 및 버전별로 UI 및 기능의 차이점을 간략하게 요약
기능, 인터페이스의 특징	제품의 기능 및 인터페이스의 특징을 간략히 요약
소프트웨어 구동 환경	개발에 사용한 언어 및 호환 가능한 운영체제에 대해 설명 설치 후 구동하기까지의 과정을 운영체제별로 설명

---

4. 사용자 매뉴얼 작성 순서

 

1. 작성 지침 정의 : 사용자 매뉴얼을 작성하기 위한 지침을 기록하며, 작성 지침은 사용자 환경에 필요한 정보를 제공할 수 있는 형태로 기록
2. 사용자 매뉴얼 구성 요소 정의 : 소프트웨어의 기능, 구성 객체 목록, 객체별 메소드, 메소드의 파라미터, 실제 사용예, 사용자 환경 셋팅 방법 등을 기록
3. 구성 요소별 내용 작성 : 사용자 매뉴얼 구성 요소별로 내용을 기록
4. 사용자 매뉴얼 검토 : 작성된 구성 요소별 내용이 올바른지, 부족한 부분은 없는지 등을 검토하여 수정 및 보완

---

섹션 14. 소프트웨어 버전 등록

 

1. 소프트웨어 패키징의 형상 관리

 

• 형상관리(SCM; Software Configuration Management)는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
• 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보
• 소프트웨어 개발의 전 단계에 적용되는 활동이며 유지보스 단계에서도 수행 됨
• 소프트웨어 개발의 전체 비용을 줄이고 개발 과정의 여러 방해 요인이 최소화 되도록 보증하는 것을 목적으로 함
• 소스 코드뿐만 아니라 프로젝트 계획, 분석서, 설계서, 프로그램, 테스트 케이스 등이 포함됨
• 가시성과 추적성을 보장함으로써 소프트웨어의 생상선과 품질을 높일 수 있음
• 대표적인 도구 : Git, CVS, Subversion 등

---

2. 형상 관리의 중요성

 

• 지속적인 소프트웨어의 변경 사항을 체계적으로 추적하고 통제할 수 있음
• 제품 소프트웨어에 대한 무절제한 변경을 방지하고 발견된 버그나 수정 사항을 추적할 수 있음
• 소프트웨어는 형태가 없어 가시성이 결핍되므로 진행 정도를 확인하기 위한 기준으로 사용될 수 있음
• 소프트웨어의 배포본을 효율적으로 관리할 수 있으며 여러 명의 개발자가 동시에 개발할 수 있음

---

3. 형상 관리 기능

 

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

---

4. 소프트웨어의 버전 등록 관련 주요 기능

 

• 개발 과정에서 코드와 라이브러리, 관련 문서 등의 버전 관리를 위해 자료를 등록하고 갱신하는 과정에서 사용되는 주요 용어와 의미

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

---

5. 소프트웨어 버전 등록 과정

 

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

---

섹션 15. 소프트웨어 버전 관리 도구

 

1. 공유 폴더 방식

 

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

*RCS(Revision Control System) : 여러 개발자가 프로젝트를 수행할 때 시간에 따른 파일 변화 과정을 관리하는 소프트웨어 버전 관리도구로 소스 파일을 동시에 수정하는 것을 방지하고 다른 방향으로 진행된 개발 결과를 합치거나 변경 내용을 추적할 수 있음

---

2. 클라이언트 / 서버 방식

 

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

---

3. 분산 저장소 방식

 

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

---

4.  Subversion(서브버전, SVN)

 

• CVS의 개선버전으로 아파치 소프트웨어 재단에서 2000년에 발표함
• 클라이언트/서버 구조로 서버에는 최신 버전의 파일들과 변경 내역이 관리됨
• 서버의 자료를 클라이언트로 복사해와 작업한 후 변경 내용을 서버에 반영(Commit)함
• 모든 개발 작업은 trunk디렉터리에서 수행되고 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어 작업을 완료한 후 trunk 디렉터리와 병합(merge)
• 커밋 할 때마다 리비전(커밋의 버전)이 1씩 증가됨
• 클라이언트는 대부분의 운영체제에서 사용되지만 서버는 주로 유닉스를 사용
• 소스가 오픈되어 있어 무료로 사용할 수 있음
• CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능함

명령어	의미
add	새로은 파일이나 디렉터리를 버전 관리 대상으로 등록 add로 등록되지 않은 대상은 commit이 적용되지 않음
commit	버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스파일에 적용
update	서버의 최신 commit이력을 클라이언트의 소스 파일에 적용 commit전체는 매번 update를 수행하여 클라이언트에 적용되지 않은 서버의 변동 내역을 클라이언트에 적용
checkout	버전 관리 정보와 소스 파일을 서버에서 클라이언트로 받아옴
lock/unlock	서버의 소스 파일이나 디렉터리를 잠그거나 해제
import	버전관리에 대한 정보를 제외한 순수한 소스 파일만을 서버에서 받아옴
info	지정한 파일에 대한 위치나 마지막 수정 일자 등에 대한 정보를 표시
diff	지정된 파일이나 경로에 대해 이전 리비전과 차이를 표시
merge	다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합

좌) SVN , 우) Git 형상관리 / 시나공 도서출처

 

---

5. Git(깃)

 

• 리누스 토발즈가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노에 의해 유지보수 되고 있음
• 분산 버전 관리 시스템으로  2개의 저장소[로컬(지역)저장소, 원격저장소]가 존재함
• 지역 저장소는 개발자들이 실제 개발을 진행하는 장소로 버전 관리가 수행됨
• 원격 저장소는 여러 사람들이 협업을 위해 버전을 공동 관리하는 곳으로 자신의 버전 관리 내역을 반영하거나 다른 개발자의 변경 내용을 가져올 때 사용
• 버전 관리가 지역 저장소에서 진행되므로 버전 관리가 식속하게 처리되고, 원격 저장소나 네트워크에 문제가 있어도 작업이 가능함
• 브랜치를 이용하면 기본 버전 관리틀에 영향을 주지 않으면서 다양한 형태의 기능테스팅이 가능함
• 파일의 변화를 스냅샷(Snapshot)으로 저장하는데, 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름을 파악할 수 있음

명령어	의미
add	작업 내역을 지역 저장소에 저장하기 위해 스테이징 영역(Staging Area)에 추가 '--all' 옵션으로 작업 디렉터리의 모든 파일을 스테이징 영역에 추가할 수 있음
commit	작업 내역을 지역 저장소에 저장
branch	새로운 브랜치를 생성 최초로 commit을 하면 마스터(master)브랜치가 생성됨 commit할 때마다 해당 브랜치는 가장 최근의 commit한 내용을 가리키데 됨 '-d'옵션으로 브랜치를 삭제할 수 있음
checkout	지정한 브랜치로 이동 현재 작업중인 브랜치는 HEAD포인터가 가리키는데, checkout 명령을 통해 HEAD포인터를 지정한 브랜치로 이동시킴
merge	지정한 브랜치의 변경 내역을 현재 HEAD포인터가 가리키는 브랜치에 반영함으로써 두 브랜치를 병합
init	지역 저장소를 생성
remote add	원격 저장소에 연결
push	로컬 저장소의 변경 내역을 원격 저장소에 반영
fetch	원격 저장소의 변경 이력만을 지정 저장소로 가져와 반영

 

순서

 

• init 명령으로 지역 저장소 생성
• remote add 명령으로 원격 저장소에 연결 후 add -all -> commit -> push
• 이후 버전 관리는 fetch -> 작업 -> add -> commit -> push 과정으로 진행
• 나머지 명령은 작업 과정 및 자료 송수신과정에서 필요에 의해 수행

---

섹션16. 빌드 자동화 도구

 

1. 빌드 자동화 도구의 개요

 

• 빌드란 소스 코드 파일을 컴파일한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정
• 이러한 빌드를 포함하여 테스트 및 배포를 자동화하는 도구를 빌드 자동화 도구라고 함
• 애자일 환경에서는 하나의 작업이 마무리될 때마다 모듈 단위로 나눠서 개발된 코드들이 지속적으로 통합되는데, 이러한 지속적인 통합(Continuous Integration) 개발 환경에서 빌드 자동화 도구는 유용하게 활용됨
• Ant, Make, Maven, Gradle, Jenkins 등이 있으며 이중 JenKins와 Gradle이 가장 대표적임

---

2. Jenkins

 

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

---

3. Gradle

 

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