2-way Merge(2웨이 머지); 2개의 파일을 하나로 합치는 것.
3-way Merge(3웨이 머지); 3개의 파일을 이용하여 머지를 하는 것으로 파일의 변경 내용을 확인하여 머지를 하기 때문에 좀 더 편리하고 정확하게 파일을 합칠 수 있다.
버그관리시스템; 버그 및 개선사항, 미래의 기능 등 제품에 관련된 모든 이슈를 등록하여 관리하기 위한 시스템.
빌드시스템; 공식빌드를 하기 위한 전용시스템이다. 빌드 환경이 완벽하게 갖추어져 있고 보통 다른 용도로 사용하지 않는다.
소스코드관리시스템; 소스코드와 개발에 필요한 문서와 자료들을 체계적으로 보관, 관리하기 위한 시스템.
요구사항관리시스템; 요구사항과 스펙을 DB를 이용하여 체계적으로 관리해주는 시스템
테스트관리시스템; 테스트 케이스와 실행 및 결과를 체계적으로 관리하는 시스템
프로젝트관리시스템; 일정관리, 인력관리, 리스크관리 등의 프로직트 관리를 하는데 사용하는 시스템.
Alpha version(알파버전); 기능이 모두 구현되었으나, 버그는 꽤 많은 상태의 버전이다. 모든 기능을 테스트 해 볼 수는 있으나 일부 작동이 안 되는 기능이 있을 수 있다.
Ant(앤트); 자바언어로 작성된 소프트웨어의 빌드 스크립트를 만들기 위해 제작된 전용 프로그래밍 언어.
B/R Team(Build/Release Team, 빌드/릴리즈팀); 빌드와 릴리즈를 전문적으로 담당하는 팀이다. 소프트웨어의 공식 빌드의 실행에 대한 책임을 가지고 있다.
Baseline(베이스라인); 소프트웨어 개발 시 변경 통제의 기준선이다.
Beta version(베타버전); 중요한 버그는 거의 수정이 되어서 작은 버그들만 남아 있는 버전이다. 베타 버전은 종종 사용자 평가(Evaluation) 및 외부 테스터(Field Test)를 위해서 외부에 배포되기도 한다.
Branch(브랜치); 소스코드를 특정 목적으로 분기하여 각각 따로 개발하는 것.
Broken Tree(브로큰 트리); 소스코드가 정상적으로 빌드과 완료되지 않는 상태.
Build(빌드); 소스코드 파일을 컴퓨터에서 실행할 수 있는 소프트웨어로 변환하는 과정.
Build Number(빌드 번호); 빌드 시 부여하는 고유 번호이다. 제품 버전과 병행하여 사용하는 것이 일반적이다.
Build Script(빌드 스크립트); 한 번의 스크립트 실행으로 빌드 전 과정이 완료될 수 있도록 만들어 놓은 스크립트.
CCB(Change Control Board, 변경관리위원회); 소프트웨어의 변경을 통제하고 관리하는 가상의 조직이다. 소프트웨어 개발 단계에서 요구사항이나 일정 등을 변경하려면 CCB의 승인을 받아야 한다.
Check in(체크인); 소스코드를 수정한 후 저장소에 소스코드를 등록하는 것.
Check out(체크아웃); 소스코드를 수정하기 위해서 저장소에서 소스코드를 로컬PC로 가져오는 것.
Clone(클론); 원격지에서 소스코드를 관리할 수 있도록 복제된 소스코드저장소를 만드는 것
Command line(커맨드 라인); 마우스를 이용하여 명령을 실행하는 것이 아니라, 키보드를 이용하여 명령어를 직접 입력할 수 있는 환경.
Commit(커밋); 체크아웃(Check-out) 한 파일을 수정하거나 파일을 추가, 삭제하는 등의 동작을 한 후에 이를 저장소에 반영하는 것이다.
Conflict(충돌); 소스코드를 서로 다른 사람이 같은 부분을 각각 다르게 수정하여 머지 시 합쳐지지 않는 경우
Cron(크론), crontab(크론탭); 시간과 날짜 등을 지정해놓고 지정된 시간에 지정된 프로그램이 실행되게 해주는 기능
Customizing(커스터마이징); 소프트웨어를 특정한 고객의 요구에 맞게 일정 부분을 바꾸는 작업.
Daily Build(일일빌드); 소프트웨어 개발 시 소스코드를 항상 빌드 가능한 상태로 유지하기 위하여 자동으로 매일 정해진 시간에 빌드하는 것. Nightly Build라고도 한다.
DVCS(분산소스코드관리시스템); 분산된 개발환경에서 소스코드를 관리하기 위해 개발된 소스코드관리시스템.
Engineering Build(엔지니어링 빌드); 개발자가 소프트웨어 구현의 목적으로 자신의 PC에서 특별한 제약 없이 행하는 빌드.
Export(익스포트); 체크아웃과는 달리 버전 관리 파일들을 뺀 순수한 원래 프로젝트 파일만을 받아오는 작업.
FCS(First Customer Shipment); 출시를 위해서 만들어진 버전이다. RC version이라고도 부른다.
Full Build(풀 빌드); 미리 컴파일 되어 있는 바이너리들을 이용하지 않고 모든 소스코드 파일을 처음부터 다시 빌드하는 것.
GA(General availability); RC버전 중에서 테스트를 통과하여 출시 할 수 있는 버전이다. RTM(Release to Manufacturing)이라고 부르기도 한다.
Gantt Chart(간트 차트); 작업계획과 일정계획의 내용을 올바르게 작업자에 이해시킴으로써 보다 쉽게 작업 통제를 하기 위하여 간트(Gantt, H.I.)가 특별히 고안한 도표.
GPL(General Public License); 무료 소프트웨어 재단(FSF)과 이 재단의 GNU 프로젝트에 의해 배포되며 GNU 소프트웨어에 적용되는 공개 소프트웨어의 대표적인 라이선스 체계.
i18n(internationalization, 국제화); 소프트웨어를 각국의 언어에 종속되지 않게 만드는 것,'i'는 대문자로 사용하면 'L'의 소문자와 헷갈릴 수가 있어서 주로 소문자로 사용한다.
IDE(Integrated Development Environment, 통합개발환경); 소프트웨어 개발을 위하여 개발자들이 사용하는 애플리케이션으로서 편집기, 컴파일러, 디버거 등이 포함되어 있다.
Import(임포트); 아무것도 들어있지 않은 저장소에 맨 처음 파일들을 넣는 작업.
Infrastructure system(기반시스템); 소프트웨어를 개발하는데 도움을 주는 시스템과 툴.
KPI(Key Performance Indicator, 핵심성과지표); 직원들의 성과를 평가하기 위하여 작성한 측정 가능한 지표.
L10n(Localization, 지역화); 소프트웩어가 특정한 언어를 지원하도록 만드는 것.
Label(레이블); 마이크로소프트 Visual SourceSafe에서 베이스라인을 설정하기 위하여 제공하는 기능. Tag참조.
Lock(락); 소스코드를 동시에 여러 사람이 수정할 경우 충돌이 나지 않도록 한 사람만 사용 가능하도록 잠그는 것.
Master File(마스터 파일); 빌드와 팩키징 과정을 거쳐서 설치가 가능하도록 만들어 놓은 파일.
Merge Tool(머지툴); 머지를 쉽게 할 수 있도록 제공되는 툴.
Merge; 2개 이상의 파일의 데이터를 하나의 파일로 합치는 작업.
Milestone(마일스톤); 소프트웨어 개발의 각 단계가 끝나는 시점.
Open Source(오픈소스); 소스코드를 공개하여 누구나 무료로 이용할 수 있도록 하고, 공개된 소스코드를 기반으로 프로그램을 수정할 수 있도록 한 것.
Packaging(팩키징); 빌드한 바이너리 파일들을 조합하여 설치 가능한 프로그램으로 만드는 일련의 작업.
Patch(패치 또는 패치 프로그램); 제품 출시 후 발견된 버그를 해결하기 위하여 제공하는 프로그램이다. Fix(픽스)라는 말을 사용하기도 한다.
Peer Review(동료검토); 소프트웩어 프로그램의 결함이나 개선 사항을 발견하기 위하여 동료가 문서나 코드를 검토, 분석하고 개선 사항을 제안하는 작업.
Perl(펄); 인터프리터 방식의 프로그래밍 언어로서 실용적이고 표현력이 뛰어나다.
Pre-alpha version(프리알파버전); 알파 이전에 만들어내는 빌드들이다. 개발 버전이라고 하기도 한다.
Prototyping(프로토타이핑); 소프트웨어 개발 기법의 하나로 기능과 성능을 검증하기 위해서 미리 소프트웨어를 간단히 만들어보는 것.
Pull(풀); 원격저장소에서 변경된 내용을 나의 저장소로 가져와서 통합하는 것.
Push(푸쉬); 나의 저장소에서 작업한 내용을 다른 원격저장소로 보내서 통합하는 것.
Python(파이선); 플랫폼 독립적인 인터프리터 식, 객체지향적 대화형 언어.
RC version(Release Candidate 버전); 출시를 위해서 만들어진 버전이다. 감마(Gamma) 또는 델타(Delta)라고 부르기도 한다.
Repository(리파지토리); 소스코드관리시스템에서 소스코드를 저장하는 공간.
Requirements Specialist(분석전문가); 소프트웨어 요구분석에 대한 전문적인 지식과 경험을 가지고 요구분석 업무를 수행하는 전문가.
Revision(리비전); 소스코드 파일 등을 수정하여 커밋(Commit)할 때마다 하나씩 증가하는 번호.
Roll back(롤백); 저장소에서 소스코드를 과거 버전으로 되돌리는 것이다.
RTM(Release to Manufacturing version); RC버전 중에서 테스트를 통과하여 출시할 수 있는 버전이다.
Smoke Test(스모크테스트); 시스템의 안정성 및 주요 기능이 제대로 작동하는가를 확인하기 위한 기본적인 테스트이다.
Software Life Cycle(소프트웨어 생애주기); 소프트웨어 탄생에서 소멸까지의 모든 활동.
Spec(스펙 또는 스펙문서); SRS와 동일한 문서.
SRS(Software Requirement Specification); 요구사항과 스펙을 정리한 요구분석 단계의 산출물로서 소프트웨어 프로젝트의 중심이 되는 문서. 회사에 따라서 요구사항 명세서, 기능 명세서 등과 같은 SRS와 유사한 문서들이 있다.
Sunken Cost(매몰 비용); 이미 지출되었으므로 회수가 불가능한 비용.
Tag(태그); Subversion이나 CVS에서 베이스라인을 설정하기 위하여 제공하는 기능. Label 참조.
TBD(To be determined); 아직 결정되지 않았고, 추후 결정할 예정이라는 표시.
TCL(Test Case List, 테스트케이스목록); 소프트웩어 테스트의 절차 및 항목을 모두 기록한 문서.
TSC(Technical Steering Committee, 최고 기술 위원회); 최고 기술 의사 결정 기구로서 회사의 중요한 기술적인 안건을 결정하는 가상 기구.
TDS(Test Design Specificaiton); 상세한 테스트 조건과 예상되는 테스트 결과를 기록한 문서.
UML(Unified Modeling Language, 객체지향 통합 모델링 언어); 객체 지향 방법론과 함께 제안된 모델링 언어 표기법의 표준.
Upgrade(업그레이드); 기존 버전의 제품을 대체하기 위하여 개발된 새로운 버전의 제품.
Waterfall Model(폭포수모델); 소프트웨어 개발의 각 단계를 확실히 매듭짓고 다음 단계로 넘어가는 가장 널리 알려져 있는 기본 소프트웨어 개발 기법.
WBS(Work breakdown structure); 수행해야 할 업무를 단계적으로 작은 크기로 나눠서 측정 가능하고 통제 가능한 단위로 나눈 것.
Wiki(위키); 웹 브라우저에서 간단 마크업 언어(markup language)를 이용해 공동 문서를 작성할 수 있고, 사용자들이 내용을 추가할 수 있는 웹 페이지 모음.