시나공 정보처리기사 필기 자료 - 매년 출제되는 키워드 찾기 259문제
시나공
컴활, 정보처리, 워드프로세서 등 IT 자격증 전문. 해설 포함 CBT, 최신 기출 자료 무료, 실기 채점 프로그램 제공
www.sinagong.co.kr
53. 연계 매커니즘 구성요소
○ 송신 시스템 : 연계 프로그램으로부터 생선된 데이터를 전송 형식에 맞게 인터페이스 테이블이나 파일로 변환한 후 송신하는 시스템
○ 수신 시스템 : 수신한 인터페이스 테이블이나 파일을 연계 프로그램에서 처리할 수 있는 형식으로 변환한 후 연계 프로그램에 반영하는 시스템
○ 연계 서버 : 송·수신 시스템 사이에 위치하여 데이터의 송·수신 현황을 모니터링하는 역할을 수행함
54. 디자인 패턴 : 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제. 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법
Singleton(싱글톤) : 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없음. 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화할 수 있음. [생성패턴]
Adapter(어댑터) : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴. 기존 클래스와 인터페이스가 일치하지 않을 때 이용 [구조 패턴]
Prototype(프로토타입) : 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴. 일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 활용. [생성 패턴]
Decorator(데코레이터) : 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴. 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현 [구조 패턴]
55. Component(컴포넌트) : 독립적인 업무 또는 기능을 수행하는 실행 코드기반으로 작성된 모듈. 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용됨. 넓은 의미로 재사용되는 모든 단위를 말함.
56. 정렬
- 2-Way 합병 정렬(Merge Sort) : 이미 정렬되어 있는 두 개의 파일을 한 개의 파일로 합병하는 정렬방식. 평군과 최악 모두 시간 복잡도는 O(Nlog2N)임
- 힙 정렬(Heap Sort) : 힙 정렬은 전이진 트리(Complete Binary Tree)를 Heap Tree로 변환하여 정렬하는 방식. 평균과 최악 모두 시간 복잡도는 O(Nlog2N)임.
- 퀵 정렬(Quick Sort) : 퀵 정렬은 레코드의 많은 자료 이동을 없애고 하나의 파일을 부분적으로 나누어 가면서 정렬하는 방법으로 키를 기준으로 작은 값은 왼쪽에, 큰 값은 오른쪽 서브파일로 분해시키는 정렬 방식. 분할과 정복을 통해 자료를 정렬. 평균 수행 시간 복잡도는 O(Nlog2N)이고, 최악의 수행 시간 복잡도는 O(N^)임.
-그 외 삽입, 선택, 버블 정렬도 있음
57. Steak(스택) : 리스트의 한쪽 끝으로만 자료의 삽입, 삭제 작업이 이루어지는 자료 구조. LIFO방식으로 자료 처리.
Queue(큐) : 리스트의 한쪽에서는 삽입 작업이 이루어지고 다른 한쪽에서는 삭제 작업이 이루어지도록 구성한 자료 구조. FIFO 방식으로 자료 처리. 시작과 끝을 표시하는 두 개의 포인터가 있음.
58. 품질 요구사항
○ 기능성(Functionality) : 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부
- 하위 특성 : 적절성/적합성(Suitability), 정밀성/정확성(Accuracy), 상호 운용성(Interoperability), 보안성(Security), 준수성(Compliance)
○ 신뢰성(Reliability) : 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도
- 하위 특성 : 성숙성(Maturity), 고장 허용성(Faut Tolerance), 회복성(Recoverability)
○ 사용성(Usability) : 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도
- 하위 특성 : 이해성(Understandability), 학습성(Learnability), 운용성(Operability), 친밀성(Attractiveness)
○ 효율성(Efficiency) : 사용자가 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지 정도를 나타냄
- 하위 특성 : 시간 효율성(Time Behaviour), 자원 효율성(Resource Behaviour)
○ 유지 보수성(Maintainability) : 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도
- 하위 특성 : 분석성(Analyzability), 변경성(Changeability), 안정성(Stability), 시험성(Testability)
○ 이식성(Portability) : 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도
- 하위 특성 : 적용성(Adaptability), 설치성(Installability), 대체성(Replaceability), 공존성(Co-existence)
61. 요구사항 검증 방법
- 요구사항 검토(Requirements Review) : 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토 담당자들이 수작업으로 분석하는 방법
○ 동료검토(Peer Review) : 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 형태
○ 워크스루(Walk Through) : 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 검토 회의를 통해 결함을 발견하는 형태의 검토 방법
○ 인스펙션(Inspection) : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견하는 형태의 검토 방법
- 프로토타이핑(Prototyping) : 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측함
- 테스트 설계 : 요구사항은 테스트할 수 있도록 작성되어야 하며, 이를 위해 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토함
- CASE 도구 활용 : 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리 및 표준 준수 여부를 확인함
62. 공통 모듈 : 여러 프로그램에서 공통적으로 사용할 수 있는 모듈 의미. 자주 사용되는 기능들을 모아놓은 것.
공통 모듈 준수 명세 기법
○ 정확성(Correctness) : 시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성
○ 명확성(Clarity) : 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성
○ 완전성(Completeness) : 시스템 구현을 위해 필요한 모든 것을 기술함
○ 일관성(Consistency) : 공통 기능들 간 상호 충돌이 발생하지 않도록 작성
○ 추적성(Traceability) : 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성
66. 스테레오 타입(Stereotype) : UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용
- <<겹화살괄호>> 사이에 표현할 형태를 기술
○ <<include>> : 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
○ <<extend>> : 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
○ <<interface>> : 인터페이스를 정의하는 경우
○ <<exception>> : 예외를 정의하는 경우
○ <<constructor>> : 생성자 역할을 수행하는 경우
67. 품질 요구사항 국제 표준
ISO/IEC 9126 : 소프트웨어의 품질 특성과 평가를 위한 표준 지침으로서 국제 표준으로 널리 사용됨
ISO/IEC 25010 : 소프트웨어 제품에 대한 국제 표준으로, 2011년에 ISO/IEC 9126을 개정하여 만듬
ISO/IEC 12119 : ISO/IEC 9126을 준수한 품질 표준으로, 테스트 절차를 포함하여 규정
ISO/IEC 14598 : 소프트웨어 품질의 측정과 평가에 필요 절차를 규정한 표준으로, 개발자, 구매자, 평가자 별로 수행해야 할 제품 평가 활동을 규정함.
69. 재사용(Reuseability) : 소프트웨어의 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지에 사용하는 것.
70. 퀵(Quick) 정렬 : 레코드의 많은 자료 이동을 없애고 하나의 파일을 부분적으로 나누어 가면서 정렬
버킷(bucket)정렬 : 레코드의 키 값을 분석하여 같은 값끼리 그 순서에 맞는 버킷에 분배하였다가 버킷의 순서대로 레코드를 꺼내어 정렬
쉘(shell)정렬 : 임의의 레코드 키와 매개변수(h)값만큼 떨어진 곳의 레코드 키를 비교하여 서로 교환해 가면서 정렬
71. 프로젝트 관리 : 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동
일정 관리, 비용 관리, 인력 관리, 위험 관리, 품질 관리가 있음
72. 이진 탐색 트리 - 최악의 경우 검색 효율이 가장 나쁜 트리 (시간 복잡도 : O(n))
AVL 트리 - 자가 균형 이진 탐색 트리. 한쪽으로 치우친 편향 이진트리가 되면 높이 균형을 유지하도록 스스로 트리의 구조 변경. 두 자식 서브트리의 높이는 항상 최대 1만큼 차이남. (시간 복잡도 : O(logn))
2-3 트리 : 내부노드의 차수가 2 또는 3인 균형 탐색 트리 (시간 복잡도 : O(log3n))
레드-블랙 트리 : 자가 균형 이진 탐핵 트리의 일종으로, 노드가 블랙 또는 레드의 색깔을 갖는 트리(시간 복잡도: O(logn))
73. 목적에 따른 테스트 종류
강도(Stress) 테스트 : 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하 시에도 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
회복(Recovery) 테스트 : 시스템에 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
성능(Performance) 테스트 : 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트로, 소프트웨어의 응답 시간, 처리량 등을 테스트
안전(Security) 테스트 : 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
구조(Structure) 테스트 : 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
회귀(Regression) 테스트 : 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
병행(Parallel) 테스트 : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
74. 형상 관리(SCM; Software Configuration Management) : 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
- 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행됨
- 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 함
- 가시성과 추적성을 보장함으로써 소프트웨어의 생산성과 품질을 높일 수 있음
형상 관리 기능
○ 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업
○ 버전 제어 : 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 자른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구를 결합시키는 작업
○ 형상 통제(변경 관리) : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선이 잘 반영될 수 있도록 조정하는 작업
○ 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
○ 형상 기록(상태 보고) : 형상의 식별, 통제, 감사 작업의 결과를 기록·관리하고 보고서를 작성하는 작업
복호화(Decryption) : 암호문을 원래의 평문으로 바꾸는 과정
크랙 : 불법적인 방법으로 소프트웨어에 적용된 저작권 보호 기술을 해제 및 무단 사용할 수 있도록 하는 기술이나 도구
75. 인터페이스 구현 검증 도구 : 인터페이스 단위 기능과 시나리오 등을 기반으로 하는 통합 테스트가 필요함
xUnit : 같은 테스트 코드를 여러 번 작성하지 않게 도와주고, 테스트마다 예상 결과를 기억할 필요가 없게 하는 자동화된 해법을 제공하는 단위 테스트 프레임워크
STAF : 서비스 호출 및 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크. 크로스 플랫폼, 분산 소프트웨어 테스트 환경을 조성할 수 있도록 지원함. 분산 소프트웨어의 경우 각 분산 환경에 설치된 데몬이 프로그램 테스트에 대한 응답을 대신하며, 테스트가 완료되면 이를 통합하고 자동화하여 프로그램을 완성함.
FitNesse : 웹 기반 테스트케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임 워크
NTAF : FitNesse의 장점인 협업 기능과 STAF의 장점인 재사용 및 확장성을 통합한 NHN의 테스트 자동화 프레임워크
Selenium : 다양한 브라우저 및 개발 언어를 지원하는 웹 애플리케이션 테스트 프레임워크
Watir : Rudy를 사용하는 애플리케이션 테스트 프레임워크
RubyNode : Ruby 내부 노드 구조에 읽기 전용 접근을 허용하는 라이브러리
78. AJAX(Asynchronous JavaScript and XML) : 자바 스크립트 등을 이용하여 클라이언트와 서버 간에 XML 데이터를 교환 및 제어함으로써 이용자가 웹 페이지와 자유롭게 상호 작용할 수 있도록 하는 비동기 통신 기술
트리거(Trigger) : 데이터베이스 시스템에서 데이터의 삽입, 갱신, 삭제 등의 이벤트가 발생할 때마다 관련 작업이 자동으로 수행되는 절차형 SQL
greedy 알고리즘 : 현재 시점에서 가장 최적의 방법을 선택하는 알고리즘.
79. 빅오 표기법(Bid-O Notation) : 알고리즘의 실행시간이 최악일 때를 표기하는 방법
○ O(1) : 입력값(n)에 관계 없이 일정하게 문제 해결에 하나의 단계만을 거침 ex) 스택의 삽입, 삭제
○ O(log2n) : 문제 해결에 필요한 단계가 입력값(n) 또는 조건에 의해 감소함 ex) 이진 트리(Binary Tree), 이진 검색(Binary Search)
○ O(n) : 문제 해결에 필요한 단계가 입력값(n)과 1:1의 관계를 가짐 ex) for문
○ O(nlog2n) : 문제 해결에 필요한 단계가 n(log2n)번만큼 수행됨 ex) 힙 정렬, 2-Way 합병 정렬
○ O(n^) : 문제 해결에 필요한 단계가 입력값(n)의 제곱만큼 수행됨 ex) 삽입 정렬, 쉘 정렬, 선택 정렬, 버블 정렬, 퀵 정렬
○ O(2(n제곱)) : 문제 해결에 필요한 단계가 2의 입력값(n) 제곱만큼 수행됨 ex) 피보나치 수열
80. 테스트 하네스 도구 : 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지우너하기 위해 생성된 코드와 데이터를 의미. 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 함
테스트 하네스의 구성요소
○ 테스트 드라이버(Test Driver) : 테스트 대상의 하위 모듈을 호출하고, 매개변수를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구 [상향식 테스트]
○ 테스트 스텁(Test Stub) : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈 [하향식 테스트]
○ 테스트 슈트(Test Suites) : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
○ 테스트 케이스(Test Case) : 사용자의 요구사항을 정확하게 준수했는지 확ㅇ니하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목의 명세서
○ 테스트 스크립트(Test Script) : 자동화된 테스트 실행 절차에 대한 명세서
○ 목 오브젝트(Mock Object) : 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
81. 소프트웨어 테스트 7가지 원칙
1. 결함 발견 : 테스트의 목적은 소프트웨어 시스템에서 결함이나 오류를 식별하는 것
2. 완벽한 테스팅은 불가능 : 소프트웨어 시스템의 복잡성으로 인해 가능한 모든 입출력, 시스템 구성의 조합을 테스트하는 것은 불가능함. 테스트는 가장 중요하고 위험한 영역에 초점을 맞춰야 하며, 효과적인 테스트를 극대화해야 함
3. 초기 테스트 : 소프트웨어 개발 생명 주기에서 가능한 일찍 시작되어야 하며 초기 테스트를 통해 개발 과정에서의 비용과 노력을 줄일 수 있음
4. 결함 집중(Defect Clustering) : 대부분의 결함이 소수의 특정 모듈에 집중해서 발생하는 것
5. 살충제 패러독스(Pesticide Paradox) : 살충제를 지속적으로 뿌리면 벌레가 내성이 생거서 죽지 않는 현상 의미하며 동일한 테스트 케이스를 반복하는 것은 테스트의 효과를 저하시킬 수 있음
6. 정황 의존적 : 테스트 전략, 기술 및 도구는 일반적인 접근 방식이 존재하지 않으며 각 프로젝트의 특정 문맥에 맞게 조정되어야 함
7. 오류-부재의 궤변(Absence of Errors Fallacy) : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없다
84. 파레토(Pareto) 법칙 : 테스트로 발견된 80%의 오류는 20%의 모듈에서 발견되므로 20%의 모듈을 집중적으로 테스트하여 효율적으로 오류를 찾자는 것
85. 해싱 함수(Hashing Function) : 임의의 길이의 입력 데이터나 메시지를 고정된 길이의 값이나 키로 변화하는 함수
○ 폴딩법(Folding) : 레코드 키 값(K)을 여러 부분으로 나눈 후 각 부분의 값을 더하거나 XOR(배타적 논리합)한 값을 홈 주소로 삼는 방식
○ 제산법(Division) : 레코드 키(K)를 해시표의 크기보다 큰 수 중에서 가장 작은 소수로 나눈 나머지를 홈 주소로 삼는 방식, 즉 h(K) = K mod Q
○ 제곱법(Mid-Square) : 레코드 키 값(K)을 제곱한 후그 중간 부분의 값을 홈 주소로 삼는 방식
○ 기수 변환법(Radix) : 키 숫자의 진수를 다른 진수로 변환시켜 주소 크기를 초과한 높은 자릿수는 절단하고, 이를 다시 주소범위에 맞게 조정하는 방법
○ 대수적 코딩법(Algebraic Coding) : 키 값을 이루고 있는 각 자리의 비트 수를 한 다항식의 계수로 간주하고, 이 다항식을 해시표의 크기에 의해 정의된 다항식으로 나누어 얻은 나머지 다항식의 계수를 홈 주소로 삼는 방식
○ 숫자 분석법(Digit Analysis, 계수 분석법) : 키 값을 이루는 숫자의 분포를 분석하여 비교적 고른 자리를 필요한 만큼 택해서 홈 주소로 삼는 방식
○ 무작위법(Random) : 난수를 발생시켜 나온 값을 홈 주소로 삼는 방식
86. AJTML(Asynchronous Javascript and XML) : AJAX기술을 사용하여 서버와 비동기적으로 데이터를 주고받기 위한 표준.
JSON(Javascript Object Natation) : 경량화된 데이터 교환 형식으로 JavaScript에서 객체를 표현하는 방법을 사용
XML(Extensible Markup Language) : 다목적 마크업 언어로 데이터를 저장하고 전송하기 위한 공통적인 형식
YAML(YAML Ain't Markup Language) : 인간이 쉽게 읽을 수 있는 데이터 직렬화 언어로, 데이터의 가독성을 높이고, 데이터 간의 관계를 쉽게 파악함
87. 결함(fault) : 오류(Error) 발생, 작동 실패(Failure) 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것을 의미.
88. 인수 테스트(Acceptance Test) : 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
- 인수 테스트는 개발한 소프트웨어를 사용자가 직접 테스트함
- 인수 테스트에 문제가 없으면 사용자는 소프트웨어를 인수하게 되고, 프로젝트는 종료 됨
○ 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법. 테스트는 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록
○ 베타 테스트 : 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 테스트 기법으로, 필드 테스팅(Field Testing)이라도도 함. 실업무를 가지고 사용자가 직접 테스트하는 것으로, 개발자에 의해 제어되지 않은 상태에서 테스트가 행해지며 발견된 오류와 사용상의 문제점을 기록하고 개발자에게 주기적으로 보고함
89. 형상관리 도구 유형
1. 공유 폴더 방식 : 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
- 개발자들이 개발이 완료된 파일을 공유 폴더에 매일 복사하면 담당자는 공유 폴더의 파일을 자기 PC로 복사한 후 컴파일 하여 이상 유무를 확인
- RCS(Revision Control System) : 다수가 파일 수정을 동시에 못하게 파일 잠금 방식으로 형상 관리. 소스 파일 수정을 한 사람만으로 제한. 다른 방향으로 진행된 개발 결과를 합치거나 변경 내용을 추적할 수 있는 소프트웨어 버전 관리 도구
2. 클라이언트/서버 방식 : 버전 과리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식
- 서버의 자료를 개발자별로 자신의 PC로 복사하여 작업한 후 변경된 내용을 서버에 반영
- 모든 버전 관리는 서버에서 수행됨
- CSV(Concurrent Versons System) : 다수의 인원이 동시에 범용적인 운영체제로 접근 가능한 도구
- SVN(Subversion) : 하나의 서버에서 소스를 손쉽게 관리할 수 있도록 도와주는 도구. 저장소를 만들어서 그곳에 소스를 저장하여 소스 중복 등의 문제 해결
3. 분산 저장소 방식 : 버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식
- 개발자별 원격 저장소의 자료를 자신의 로컬 저장소로 복사하여 작업한 후 변경된 내용을 로컬 저장소에서 우선 반영(버전 관리)한 다음 이를 원격 저장소에 반영
- 로컬 저장소에서 버전 관리가 가능하므로 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용하여 작업 가능
- Git : Git 속도에 중점을 둔 분산형 버전 관리 시스템. 전 세계적으로 가장 많이 사용하며 대형 프로젝트에서 효과적. Git의 작업 폴더는 전체 기록과 각 기록을 추적할 수 있는 정보를 포함하는 완전한 형태의 저장소임
RTS(Reliable Transfer Service) : 데이터 통신에서 신뢰성이 보장된 전송 서비스를 제공하는 프로토콜
RPC(Remote Procedure Call) : 네트워크 상에서 원격지의 다른 프로세스나 컴퓨터에서 실행 중인 함수나 프로시저를 호출하는 프로토콜
RVS(Relative Version System) : 파일의 상대적인 버전을 관리하는 도구로, 각 파일 버전의 차이를 저장하여 파일 복원과 변경 이력을 추적
90. 디지털 저작권 관리(DRM)의 구성요소
○ 클리어링 하우스(Clearing House) : 저작권에 대한 사용권한, 라이선스 발급, 암호화된 키 관리, 사용량에 따른 결제 관리 등을 수행하는 곳
○ 콘텐츠 제공자(Contents Provider) : 콘텐츠를 제공하는 저작권자
○ 패키저(Packager) : 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램
○ 콘텐츠 분배자(Contents Distributor) : 암호화된 콘텐츠를 유통하는 곳이나 사람
○ 콘텐츠 소비자(Cutomer) : 콘텐츠를 구매해서 사용하는 주체
○ DRM 컨트롤러(DRM Controller) : 배포된 콘텐츠의 이용 권한을 통제하는 프로그램
○ 보안 컨테이너(Security Container) : 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치
91. 소스 코드 최적화 : 나쁜 코드(Bad Code)를 배제하고, 클린 코드(Clean Code)로 작성하는 것
- 클린 코드(Clean Code) : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드, 즉 잘 작성된 코드를 의미- 클린 코드 작성 원칙
○ 가독성 : 누구든지 코드를 쉽게 읽을 수 있도록 이해하기 쉬운 용어를 사용하거나 들여쓰기 기능 등을 사용함
○ 단순성 : 한 번에 한 가지를 처리하도록 코드를 간단하게 작성하고 클래스/메소드/함수 등을 최소 단위로 분리함
○ 의존성 배제 : 코드가 다른 모듈에 미치는 영향을 최소화하여 코드 변경 시 다른 부분에 영향이 없도록 작성함
○ 중복성 최소화 : 중복된 코드는 삭제하고 공통된 코드를 사용하여 코드의 중복을 최소화함
○ 추상화 : 상위 클래스/메소드/함수에서는 간략하게 애플리케이션의 특성을 나타내고, 상세 내용은 하이 클래스/메소드/함수에서 구현함
- 나쁜 코드(Bad Code) : 프로그램의 로직이 복잡하고 이해하기 어려운 코드
○ 스파게티 코드(Spaghetti code) : 코드의 로직이 서로 복잡하게 얽혀 있는 코드
○ 외계인 코드(Alien Code) : 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
92.
회귀 테스트 : 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 의미하는 회귀 버그를 찾는 모든 소프트웨어
테스트 방식. 이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법을 많이 사용
빅뱅 테스트 : 시스템을 구성하는 모듈을 따로 구현하고 전체 시스템을 단번에 묶어 시험하는 방법으로 모듈의 인터페이스와 결합을 테스트함
95. 스키마 : 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합
○ 외부 스키마 : 사용자나 응용 프로그래머가 각 개인의 입장에서 필요로하는 데이터베이스의 논리적 구조를 정의한 것
○ 개념 스키마 : 데이터베이스의 전체적인 논리적 구조로서, 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스로 하나만 존재함
○ 내부 스키마 : 물리적 저장장치의 입장에서 본 데이터베이스 구조로서, 실제로 데이터베이스에 저장될 레코드의 형식을 정의하고 저장 데이터 항목의 표현 방법, 내부 레코드의 물리적 순서 등을 나타냄
97. 테스트와 디버깅의 목적 : 테스트를 통해 오류를 발견한 후 디버깅을 통해 오류가 발생한 소스 코드를 추적하여 수정함
98. 테스트 자동화 : 사람이 반복적으로 수행하던 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적인 테스트를 수행할 수 있도록 한 것
테스트 자동화 도구의 유형
○ 정적 분석 도구(Static Analysis Tools) : 프로그램을 실행하지 않고 분석하는 도구로, 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함 등을 발견하기 위해 사용
○ 테스트 케이스 생성 도구(Test Case Generation Tools)
- 자료 흐름도 : 자료 원시 프로그램을 입력받아 파싱한 후 자료 흐름도를 작성함
- 기능 테스트 : 주어진 기능을 구동시키는 모든 가능한 상태를 파악하여 이에 대한 입력을 작성함
- 입력 도메인 분석 : 원시 코드의 내부를 참조하지 않고, 입력 변수의 도메인을 분석하여 테스트 데이터를 작성함
- 랜덤 테스트 : 입력 값을 무작위로 추출하여 테스트함
○ 테스트 실행 도구(Test Execution Tools) : 스크립트 언어를 사용하여 테스트를 실행하는 방법으로, 테스트 데이터와 테스트 수행 방법 등이 포함된 스크립트를 작성한 후 실행함
- 데이터 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장하고, 이를 읽어 실행하는 방식
- 키워드 주도 접근 방식 : 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행하는 방식
○ 성능 테스트 도구(Test Control Tools) : 애플리케이션의 처리량, 응답 시간 경과 시간, 자원 사용률 등을 인위적으로 적용한 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인함
○ 테스트 통제 도구(Test Control Tools) : 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구로, 종류에는 형상 관리 도구, 결함 추적/관리 도구 등이 있음
○ 테스트 하네스 도구 : 테스트 하네스는 애플리케이션의 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위해 생성된 코드와 데이터를 의미함. 테스트 하네스 도구는 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 함.
명세 기반 테스트 : 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트 ex) 동등 분할, 경계 값 분석 등
기능 테스트 : 블랙박스 테스트, 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
99. 소프트웨어의 버전 등록 관련 주요 기능
저장소(Repository) : 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
가져오기(Import) : 버전 관리가 되고 있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사함
체크아웃(Check-Out) : 프로그램을 수정하기 위해 저장소에서 소스 파일과 함께 버전 관리를 위한 파일들을 받아옴
체크인(Check-In) : 체크아웃 한 파일의 수정을 완료한 후 저장소의 파일을 새로운 버전으로 갱신함
커밋(Commit) : 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌을 알리고 diff 도구를 이용해 수정한 후 갱신을 완료함
동기화(Update) : 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화함