정보처리기사 필기 소프트웨어 개발 요약

정렬 알고리즘들의 시간복잡도와 특징

정렬 알고리즘	평균 시간복잡도	최악 시간복잡도	최선 시간복잡도	안정 정렬	특징
버블 정렬	O(N²)	O(N²)	O(N)	예	인접한 원소끼리 반복 교환
선택 정렬	O(N²)	O(N²)	O(N²)	아니오	항상 N², 불필요한 교환 많음
삽입 정렬	O(N²)	O(N²)	O(N)	예	거의 정렬된 자료에 유리
합병 정렬	O(N log N)	O(N log N)	O(N log N)	예	분할 정복 기반, 안정적
퀵 정렬	O(N log N)	O(N²)	O(N log N)	아니오	평균적으로 빠르나 피벗 선택에 따라 성능 차이 큼
힙 정렬	O(N log N)	O(N log N)	O(N log N)	아니오	힙 자료구조 사용, 불안정 정렬

 

White Box Testing (흰 상자 테스트)

정의: 프로그램의 소스 코드와 내부 구조를 알고 테스트를 수행하는 방법입니다. 구조적 테스트라고도 하며,

        테스트는 내부 로직과 경로를 중심으로 수행됩니다.

주요 종류:

1. 기본 경로 테스트 (Base Path Testing)
   • 가장 중요한 테스트 기법 중 하나로, 프로그램의 가능한 경로 중 기본 경로를 테스트합니다.
   • 복잡도가 높은 프로그램에서 사용됩니다.
2. 조건 검사 (Condition Testing)
   • 조건문(if문 등)의 각 조건이 참/거짓인 경우를 테스트합니다.
   • True/False 값을 각각 테스트하여 조건이 정확하게 작동하는지 확인합니다.
3. 루프 테스트 (Loop Testing)
   • 반복문(for, while 등)을 대상으로 테스트합니다.
   • 반복문이 예상대로 작동하는지, 무한 루프가 발생하지 않는지 검사합니다.
4. 경로 테스트 (Path Testing)
   • 프로그램 내 모든 가능한 경로를 따라가며 테스트합니다.
   • 경로 수가 많을 때 효율적으로 테스트할 수 있는 방법을 설계합니다.
5. 데이터 흐름 테스트 (Data Flow Testing)
   • 프로그램 내 데이터가 흐르는 경로를 분석하고, 데이터의 사용 및 정의가 일치하는지 확인합니다.
   • 변수의 할당과 사용의 정확성 체크를 합니다.

특징:

• 내부 구조에 대한 지식이 필요합니다.
• 주로 소스 코드의 논리적 결함을 찾습니다.
• 디버깅에 유용하고, 최적화가 필요할 수 있는 코드 영역을 찾아냅니다.
• 코드의 경로를 기준으로 테스트를 진행합니다.

 

Black Box Testing (검은 상자 테스트)

정의: 프로그램의 내부 구조를 알지 못하고, 입력과 출력만을 기반으로 테스트하는 방법입니다.

         주로 기능적 테스트로, 프로그램이 요구된 대로 동작하는지 확인합니다.

주요 종류:

1. 경계값 분석 (Boundary Value Analysis)
   • 입력 값의 경계값을 테스트합니다.
   • 경계값을 잘못 처리할 경우 오류가 발생할 수 있기 때문에 중요한 테스트 기법입니다.
2. 등가 분할 (Equivalence Partitioning)
   • 입력 데이터를 여러 동등 클래스로 나누고, 각 클래스에서 대표 값을 선택하여 테스트합니다.
   • 데이터의 범위가 크거나 다양한 경우 효율적인 테스트를 할 수 있습니다.
3. 결정 테이블 테스트 (Decision Table Testing)
   • 프로그램의 조건과 동작을 테이블 형태로 나타내고, 가능한 모든 조건 조합을 테스트합니다.
   • 조건의 조합에 따른 출력을 체크합니다.
4. 상태 전이 테스트 (State Transition Testing)
   • 시스템이 특정 상태에서 다른 상태로 전이될 때 올바르게 작동하는지 테스트합니다.
   • 상태 머신을 모델로 하는 시스템에서 유용합니다.
5. 사용자 인터페이스 테스트 (UI Testing)
   • 사용자가 프로그램을 인터페이스를 통해 사용하는 방식에 대한 테스트입니다.
   • 입력값의 유효성, 오류 처리, 반응 속도 등을 테스트합니다.

특징:

• 내부 구조를 알 필요가 없고, 오직 입력과 출력만을 기준으로 테스트합니다.
• 주로 기능적 요구 사항이 올바르게 수행되는지 확인합니다.
• 다양한 입력을 통해 시스템이 요구된 대로 반응하는지 확인합니다.
• 자동화가 용이하고, 시스템의 사용성을 평가할 수 있습니다.

비교

	White Box Testing	Black Box Testing
내부 구조 이해	필수 (소스 코드 분석)	불필요 (입력과 출력만 확인)
테스트 범위	코드의 구조적 결함	기능적 요구 사항의 충족 여부
예시 기법	Base Path, 조건 검사, 루프 테스트, 데이터 흐름 테스트	경계값 분석, 등가 분할, 결정 테이블, 상태 전이 테스트
테스트 대상	코드의 로직	시스템의 입력/출력
장점	디버깅에 유용, 내부 결함 발견	요구 사항 충족 여부 확인, 사용성 테스트

결론:

• White Box Testing은 내부의 세부 로직을 확인하고 최적화하는 데 유리합니다. 주로 개발자가 소스 코드를 직접 분석하면서 수행합니다.
• Black Box Testing은 기능적 요구 사항에 따라 시스템이 올바르게 동작하는지 확인하는 데 적합하며, 사용자 관점에서 테스트를 진행합니다.

 

EAI(Enterprise Application Integration)

 EAI(Enterprise Application Integration)는 기업 내 여러 개의 애플리케이션 시스템을 통합하여 서로 원활하게 데이터를 교환하고 협업할 수 있도록 하는 기술적 접근입니다. 이를 통해 기업 내 다양한 시스템(ERP, CRM, SCM 등)과 애플리케이션들이 서로 통합되고 효율적으로 데이터를 공유할 수 있습니다. EAI는 비즈니스 프로세스를 최적화하고 정보의 흐름을 자동화하는 데 중요한 역할을 합니다.

EAI의 주요 목적

• 애플리케이션 통합: 서로 다른 플랫폼과 기술 스택을 사용하는 애플리케이션 간의 데이터를 통합하여 비즈니스 프로세스를 자동화합니다.
• 비즈니스 효율성 향상: 중복된 업무를 줄이고, 업무 처리 속도를 빠르게 하여 업무 효율성을 향상시킵니다.
• 실시간 데이터 처리: 실시간 데이터 전송을 통해 비즈니스 프로세스가 즉시 반영되도록 합니다.
• 유연성 및 확장성 제공: 새로운 시스템을 추가하거나 변경할 때 기존 시스템에 최소한의 영향을 미치도록 지원합니다.

EAI의 주요 구성 요소

1. Middleware (미들웨어):
   • EAI 시스템에서 중심적인 역할을 하는 소프트웨어로, 애플리케이션 간의 데이터를 중개하고, 메시지를 전송하는 역할을 합니다.
   • 예: ESB(Enterprise Service Bus), Message Queueing 시스템 등.
2. Integration Tools (통합 도구):
   • EAI 솔루션을 구축하기 위한 도구들입니다. 예를 들어, ETL(Extract, Transform, Load) 도구는 데이터 변환 및 로딩을 담당합니다.
3. Adapters (어댑터):
   • 다양한 시스템과의 연결을 위해 시스템별 어댑터를 사용합니다. 이 어댑터는 시스템 간의 프로토콜 차이를 해결하고, 데이터 포맷을 변환합니다.
4. Transformation Engines (변환 엔진):
   • 데이터가 서로 다른 시스템 간에 전송될 때, 데이터 포맷 변환을 담당하는 엔진입니다.

EAI 구축 아키텍처 유형

EAI를 구현하는 방식은 여러 가지가 있으며, 각 방식은 애플리케이션 간의 연결과 데이터 흐름을 다루는 방식에 따라 달라집니다. 주요 구축 유형은 다음과 같습니다:

1. Point-to-Point (P2P):
   • 각 애플리케이션이 직접 연결되어 데이터를 주고받는 방식입니다.
   • 단점: 애플리케이션 수가 늘어날수록 연결 관리가 복잡해지고, 확장성에 한계가 있습니다.
   • 예: A와 B 시스템, B와 C 시스템 등 모든 시스템을 직접 연결해야 하는 방식.
2. Hub-and-Spoke:
   • 중앙 허브를 두고 모든 시스템이 이 허브를 통해 연결되는 방식입니다.
   • 장점: 중앙 집중식 관리가 가능하고, 새로운 시스템을 추가할 때 유연하게 처리할 수 있습니다.
   • 예: 허브에 연결된 여러 시스템이 중앙에서 데이터를 주고받는 방식.
3. Message Bus:
   • 시스템 간의 메시지를 버스 형태로 전송하는 방식입니다. 주로 **서비스 지향 아키텍처(SOA)**에서 사용됩니다.
   • 장점: 다양한 서비스와 애플리케이션 간에 메시지를 효율적으로 관리하고 처리할 수 있습니다.
   • 예: ESB(Enterprise Service Bus) 시스템을 통해 메시지를 교환하는 방식.

EAI의 장점

1. 통합성: 여러 애플리케이션 간에 일관된 데이터 흐름을 유지할 수 있어, 시스템 간의 상호운용성이 강화됩니다.
2. 비즈니스 민첩성 향상: EAI를 통해 빠르게 변화하는 비즈니스 환경에 적응하고 신속한 의사결정을 지원할 수 있습니다.
3. 효율적인 데이터 관리: 데이터를 중앙에서 관리하고 처리할 수 있어, 데이터의 일관성과 정확성이 보장됩니다.
4. 비용 절감: 시스템 간의 중복된 작업을 줄여주고, 자동화된 데이터 흐름으로 인해 인적 자원과 시간을 절약할 수 있습니다.

EAI의 단점

1. 복잡성: 다양한 시스템을 통합하기 위한 설계와 구현이 복잡하며, 고도의 기술적 역량이 필요합니다.
2. 유지보수 비용: 시스템을 통합하고 유지보수하는 데 지속적인 비용이 발생할 수 있습니다.
3. 성능 문제: 통합 과정에서 시스템 간의 성능 차이가 발생할 수 있으며, 이를 해결하기 위한 추가적인 조치가 필요할 수 있습니다.

EAI 솔루션 예시

1. Apache Camel: 경량화된 ESB 솔루션으로, 다양한 시스템 간 메시지 전송을 지원합니다.
2. MuleSoft: 강력한 API 관리 및 서비스 통합을 위한 플랫폼입니다.
3. IBM Integration Bus (IIB): IBM의 고급 ESB 솔루션으로, 다양한 시스템 간의 통합을 지원합니다.

결론:

 EAI는 기업 내 여러 애플리케이션과 시스템이 원활하게 협업할 수 있도록 도와주는 중요한 기술로, 이를 통해 업무 효율성, 정보 흐름 자동화, 비즈니스 민첩성 등을 향상시킬 수 있습니다. 다양한 아키텍처와 도구를 통해 각기 다른 요구에 맞춘 통합을 할 수 있습니다.

 

이진 트리(Binary Tree)

전위순회(Pre-order), 중위순회(In-order), 후위순회(Post-order)는 이진 트리(Binary Tree)의 순회 방법으로, 트리의 각 노드를 방문하는 순서가 다릅니다. 이 방법들은 트리 구조의 데이터를 순차적으로 접근하고 처리하는 데 사용됩니다.

1. 전위순회 (Pre-order Traversal)

• 방문 순서: 루트 → 왼쪽 → 오른쪽
• 설명: 트리의 루트를 먼저 방문하고, 그 다음에 왼쪽 서브트리, 마지막으로 오른쪽 서브트리를 방문합니다.
• 특징: 루트를 먼저 처리하고 그 후 왼쪽과 오른쪽을 차례대로 처리합니다.

예시:

• 전위순회: A → B → D → E → C

2. 중위순회 (In-order Traversal)

• 방문 순서: 왼쪽 → 루트 → 오른쪽
• 설명: 왼쪽 서브트리를 먼저 방문하고, 그 다음에 루트, 마지막으로 오른쪽 서브트리를 방문합니다.
• 특징: 이 방식은 **이진 탐색 트리(BST)**에서 정렬된 순서로 노드를 방문하는 특징이 있습니다.

예시:

• 중위순회: D → B → E → A → C

3. 후위순회 (Post-order Traversal)

• 방문 순서: 왼쪽 → 오른쪽 → 루트
• 설명: 왼쪽 서브트리를 먼저 방문하고, 그 다음에 오른쪽 서브트리, 마지막으로 루트를 방문합니다.
• 특징: 서브트리를 먼저 처리하고, 그 후 루트를 처리합니다.

예시:

• 후위순회: D → E → B → C → A

간단한 예제

위의 트리 예시에서 각 순회의 결과를 비교해 보겠습니다:

트리 구조:

• 전위순회: A → B → D → E → C
• 중위순회: D → B → E → A → C
• 후위순회: D → E → B → C → A

정리

• 전위순회는 루트를 먼저 방문하고, 그 후 왼쪽과 오른쪽을 차례대로 방문합니다.
• 중위순회는 왼쪽 서브트리, 루트, 오른쪽 서브트리 순서대로 방문합니다.
• 후위순회는 왼쪽과 오른쪽 서브트리를 먼저 방문하고, 마지막에 루트를 방문합니다.

이러한 순회 방식은 이진 트리의 다양한 작업(예: 트리 구조 출력, 트리 변형, 트리 순차 처리 등)을 구현할 때 유용하게 사용됩니다.

 

경계값 분석(Boundary Value Analysis, BVA)

경계값 분석(Boundary Value Analysis, BVA)은 소프트웨어 테스트 기법 중 하나로, 입력 값의 경계 조건(경계 근처 값)에 초점을 맞춰 테스트 케이스를 설계하는 방법입니다.

✅ 경계값 분석 기법이란?

 경계값 분석은 입력값이 특정한 범위를 가질 때, 그 범위의 가장자리(경계)에서 오류가 발생할 가능성이 높다는 점에 착안하여, 경계 주변의 값들을 집중적으로 테스트하는 기법입니다.

• 범위 내에서 중간값보다 경계 근처에서 오류가 발생할 확률이 높음
• 등가 클래스 분할 기법과 자주 함께 사용됨

📌 예시

예를 들어 입력 값이 1 ~ 100 사이의 값을 허용한다고 할 때,

• 정상 경계값:
  • 최소값: 1
  • 최대값: 100
• 경계 근처 값(테스트 대상):
  • 경계 직전 값: 0
  • 경계값: 1
  • 경계 바로 다음 값: 2
  • 최대값 -1: 99
  • 최대값: 100
  • 최대값 +1: 101

➤ 이렇게 경계를 기준으로 **[경계 이전, 경계값, 경계 다음]**의 값을 테스트하는 것이 핵심입니다.

 

🎯 적용 예시

조건: 입력값은 1~100 사이의 정수
테스트 케이스:

• 0 (경계값 -1, 오류 발생 예상)
• 1 (경계 시작값)
• 2 (경계 시작값 +1)
• 99 (경계 끝값 -1)
• 100 (경계 끝값)
• 101 (경계 끝값 +1, 오류 발생 예상)

🔍 특징 요약

항목내용

목적	경계에서의 오류 발견
사용 위치	입력 값이 범위를 가지는 경우
장점	효율적으로 결함을 발견 가능
단점	범위 외의 로직 오류는 발견 어려움

✅ 경계값 분석 vs 등가 클래스 분할

구분경계값 분석(BVA)등가 클래스 분할(ECP)

초점	경계값 근처	같은 의미의 입력 범위
테스트 케이스 수	적지만 정확한 포인트	범위별 대표값만 선택
오류 발견 가능성	경계에서 발생하는 오류에 적합	입력값 유효성/범위 오류 발견에 유리

 

ISO/IEC 9126 소프트웨어 품질 특성

ISO/IEC 9126은 소프트웨어의 품질을 다음과 같은 6가지 주요 특성과 그 하위 특성들로 분류합니다:

📌 1. 기능성 (Functionality) 하위 특성:

하위 특성설명

적합성 (Suitability)	주어진 목적에 적합한 기능을 제공하는가
정확성 (Accuracy)	결과가 정확하게 도출되는가
상호운용성 (Interoperability)	다른 시스템과 상호작용할 수 있는가
보안성 (Security)	접근 제어 및 데이터 보호 기능이 있는가
기능성 준수성 (Functionality Compliance)	표준이나 규범을 잘 따르는가

📌 2. 사용성 (Usability) 하위 특성 (참고)

하위 특성설명

이해성 (Understandability)
학습성 (Learnability) ← ❗ 문제 보기의 1번
운용성 (Operability)
사용성 준수성 (Usability Compliance)

 

31. 다음 트리의 차수(degree)와 단말 노트(terminal node)의 수는?

 

1. 차수 : 4, 단말 노드 : 4

2. 차수 : 2, 단말 노드 : 4

3. 차수 : 4, 단말 노드 : 8

4. 차수 : 2, 단말 노드 : 8

 

✅ 용어 정리

🔹 차수(Degree)

• 한 노드가 가진 자식 노드의 수를 의미합니다.
• 예를 들어 자식이 2개면 차수 2, 자식이 없으면 차수 0입니다.
• 전체 트리에서는 가장 높은 차수를 가진 노드의 값을 트리의 최대 차수로 부릅니다.

🔹 단말 노드(Leaf Node)

• 자식 노드가 없는 노드, 즉 차수가 0인 노드를 말합니다.

 

소스코드 품질분석 도구

✅ 1. 정적 분석 도구 (Static Analysis Tools)

• 코드를 실행하지 않고 소스 코드 자체를 분석하여 문법 오류, 스타일 위반, 보안 취약점, 코드 품질 문제 등을 찾아냄
• 컴파일 전 또는 개발 단계에서 주로 사용됨
• 장점: 빠르게 피드백 가능, 조기 버그 탐지

🔹 대표 도구

도구 이름지원 언어주요 기능

PMD	Java	코드 스타일 위반, 불필요 코드 탐지
Checkstyle	Java	코딩 규칙 위반 검사
FindBugs / SpotBugs	Java	잠재적 버그 분석
Cppcheck	C, C++	문법 오류, 메모리 오류 분석
SonarQube	다수 언어	품질, 보안 취약점 정적 분석
ESLint	JavaScript	문법 오류, 스타일 검사
Flake8 / Pylint	Python	문법, 스타일, 코드 품질 검사

 

✅ 2. 동적 분석 도구 (Dynamic Analysis Tools)

• 코드를 실제로 실행하면서 런타임 시 발생하는 오류, 메모리 누수, 성능 문제, 보안 취약점 등을 분석
• 테스트나 운영 환경에서 사용됨
• 장점: 실행 중 오류 탐지, 실시간 성능 정보 수집 가능

🔹 대표 도구

도구 이름용도주요 기능

valgrind	C, C++	메모리 누수, 메모리 오류 탐지
JProfiler	Java	메모리, 스레드, 성능 분석
VisualVM	Java	CPU/메모리 사용량 실시간 모니터링
Dynatrace	다양한 플랫폼	APM, 성능 모니터링
AppDynamics	다양한 플랫폼	성능 모니터링 및 트랜잭션 추적
valMeter	시스템 성능 분석	실행 시간, 리소스 소비 분석

 

✅ 요약 표

분석 방식도구 예시실행 필요 여부분석 목적

정적 분석	PMD, Checkstyle, SonarQube, ESLint	❌ 실행하지 않음	문법 오류, 스타일, 보안 등 사전 진단
동적 분석	valgrind, JProfiler, VisualVM	✅ 실행 필요	런타임 오류, 메모리 누수, 성능 분석

 

알고리즘 설계 기법 정리

1. 분할 정복 (Divide and Conquer)

• 개념: 문제를 작은 하위 문제로 분할하고, 각각을 재귀적으로 해결한 후, 결과를 병합하여 전체 문제를 해결.
• 절차: Divide → Conquer → Combine
• 대표 예제:
  • Merge Sort (병합 정렬)
  • Quick Sort (퀵 정렬)
  • 이진 탐색 (Binary Search)

2. 동적 계획법 (Dynamic Programming)

• 개념: **중복되는 하위 문제의 결과를 저장(Memoization)**하여 불필요한 계산을 줄이는 방식.
• 조건: 최적 부분 구조, 중복 부분 문제
• 대표 예제:
  • 피보나치 수열
  • 배낭 문제 (Knapsack Problem)
  • 최장 공통 부분 수열 (LCS)

3. 탐욕법 (Greedy Algorithm)

• 개념: 매 단계에서 현재 상황에서 가장 최적이라고 생각되는 선택을 하는 기법.
• 조건: 탐욕적 선택 속성과 최적 부분 구조가 만족돼야 최적해 보장 가능
• 대표 예제:
  • 동전 거스름돈 문제
  • Kruskal 알고리즘 (최소 신장 트리)
  • Dijkstra 알고리즘 (최단 경로)

4. 백트래킹 (Backtracking)

• 개념: 가능한 해를 찾기 위해 탐색하다가 조건이 맞지 않으면 되돌아가는(Backtrack) 방식.
• 대표 예제:
  • N-Queen 문제
  • 미로 찾기
  • 순열 / 조합 생성

5. 분지 한정 (Branch and Bound)

• 개념: 백트래킹과 유사하나, **최적해를 찾기 위한 조건(한정 조건)**을 사용하여 불필요한 분기 줄임
• 대표 예제:
  • 외판원 문제 (TSP)
  • 0/1 Knapsack 문제

6. 완전 탐색 (Brute Force)

• 개념: 가능한 모든 경우의 수를 무식하게 전부 탐색하여 정답을 찾는 방법.
• 장점: 구현이 쉬움
• 단점: 비효율적, 시간이 오래 걸림
• 대표 예제:
  • 비밀번호 조합 찾기
  • 순열로 가능한 값 찾기

📌 요약표

기법	핵심 아이디어	대표 예
분할 정복	문제 나눠 풀고 병합	Merge Sort, 이진 탐색
동적 계획법	하위 결과 저장 재사용	LCS, 피보나치
탐욕법	매 순간 최선 선택	동전 문제, Dijkstra
백트래킹	조건 안 맞으면 되돌아감	N-Queen, 미로
분지 한정	가지치기로 불필요한 경로 제거	TSP
완전 탐색	모든 경우 탐색	순열 문제

 

파티션(Partition)이란?

 파티션은 하나의 테이블이나 인덱스를 논리적으로 나누어 저장하는 물리적 구획입니다.
이는 대량의 데이터를 보다 효율적으로 관리하고 빠르게 액세스할 수 있도록 돕습니다.

🔹 1. 범위 분할 (Range Partitioning)

• 개념: 데이터를 특정 컬럼의 값 범위에 따라 나누는 방식
• 적용 예시:

범위 분할

• 사용 사례: 날짜, 연속 숫자 등 정렬된 데이터를 다룰 때 적합
• 장점: 시간 순으로 조회/삭제/보관하기 쉬움

🔹 2. 해시 분할 (Hash Partitioning)

• 개념: 특정 컬럼 값을 해시 함수로 처리해 파티션을 나누는 방식
• 적용 예시:

해시 분할

• 사용 사례: 고객 번호, 주문 번호 등에서 균등하게 데이터를 분산시킬 때
• 장점: 파티션 간 데이터 불균형이 적음 (로드 밸런싱 유리)

🔹 3. 조합 분할 (Composite Partitioning)

• 개념: 두 가지 이상의 파티션 방법을 혼합해서 사용하는 방식
  (예: 먼저 범위 분할 → 그 안에서 해시 분할)
• 적용 예시:
   

조합 분할

• 사용 사례: 날짜별로 구분하면서도, 내부 데이터를 고르게 분산시키고 싶은 경우
• 장점: 다양한 조건을 만족할 수 있어 유연하고 확장성 높음

🔹 4. 리스트 분할 (List Partitioning)

• 개념: 컬럼의 값을 기반으로 명시된 값 목록에 따라 파티션
• 적용 예시:

• 사용 사례: 지역 코드, 상품 분류처럼 고정된 값의 범주에 따라 구분할 때
• 장점: 범주형 데이터에 적합

🔹 5. 키 분할 (Key Partitioning)

• 개념: 해시 분할의 변형으로, DBMS가 내부적으로 해시 함수를 지정
• 차이점: 사용자가 해시 함수를 지정하지 않음
• 사용 사례: Oracle 등 일부 DBMS 전용 옵션

📌 요약 표

파티션 유형	기준	장점	사용 예
범위 분할	연속된 값(날짜 등)	시간 순 처리 유리	월별 데이터
해시 분할	해시 함수	데이터 균등 분산	사용자 ID
조합 분할	범위 + 해시	유연하고 확장성 높음	시간 + ID
리스트 분할	정해진 목록	범주형 데이터에 적합	지역별, 상품군
키 분할	DB 지정 해시	설정 단순

 

저작권 관리(DRM)의 주요 구성 요소와 역할

1. 콘텐츠 제공자 (Contents Provider)

• 콘텐츠의 저작권자 또는 제작자
• 영상, 음악, 문서 등의 디지털 콘텐츠를 제작하고 등록
• DRM 시스템에 콘텐츠를 등록하여 배포 준비 

2. 콘텐츠 분배자 (Contents Distributor) 

• 콘텐츠를 사용자가 받을 수 있도록 패키징 및 유통하는 사
• 메타데이터(콘텐츠 설명, 권한 정보 등)를 함께 포함
• 예: 온라인 서점, 스트리밍 플랫폼 

3. 클리어링 하우스 (Clearing House) 

• 정산, 사용 기록 관리, 저작권료 분배 등을 수행
• 사용자가 콘텐츠를 이용한 내역을 기록하고, 이에 따라 저작권자에게 정산
• 거래의 중재 및 인증 역할을 하며, 직접 키 관리는 하지 않음 

4. DRM 컨트롤러 (DRM Controller) 

• 이용 권한 통제, 인증 및 접근 제어 담당
• 사용자의 라이선스를 확인하고, 권한이 없을 경우 콘텐츠 접근을 차단
• 암호화된 콘텐츠를 재생하거나 열람할 수 있도록 제어 

5. 라이선스 서버 (License Server) 

• DRM 컨트롤러와 함께 동작
• 사용자 요청에 따라 라이선스 발급 및 암호화 키 전달
• 콘텐츠 이용 범위(예: 시청 가능 기간, 다운로드 가능 여부 등)를 지정한 사용 정책 전달

🔁 DRM 작동 흐름 예시

1. 콘텐츠 제공자가 콘텐츠 등록 → DRM으로 암호화됨
2. 분배자가 암호화된 콘텐츠를 사용자에게 배포
3. 사용자가 콘텐츠를 실행하면 DRM 컨트롤러가 권한을 확인
4. 사용자의 권한이 확인되면 라이선스 서버로부터 키를 받아 재생 허용
5. 콘텐츠 이용 내역은 클리어링 하우스로 전달되어 정산 및 기록

✅ 요약

역활	관리 내용
Contents Provider	콘텐츠 제공 및 등록
Contents Distributor	콘텐츠 패키징 및 유통
Clearing House	정산, 사용 기록 관리
DRM Controller	콘텐츠 접근 통제, 권한 확인
License Server	키, 라이선스 발급 및 정책 전달

 

24. 다음 전위식(prefix)을 후위식(postfix)으로 옳게 표현한 것은?

- / * A + B C D E

 

1. A B C + D / * E -
2. A B * C D / + E -
3. A B * C + D / E -
4. A B C + * D / E -

 

주어진 전위식: - / * A + B C D E

 

이를 후위식으로 바꾸기 위해서는 전위식을 중위식으로 바꾸고 후위식으로 변환한다.

전위식(연산자 -> 데이터 -> 데이터) -> 중위식(연산자 가운데)

(1) - / * A + B C D E

->  - / * A (B + C) D E

(2) - / * A (B + C) D E

->  - / A * (B + C) D E

(3) - / A * (B + C) D E

->  -  A * (B + C) / D E

(4) -  A * (B + C) / D E

-> A * (B + C) / D - E (중위식) 최후

 

후위식(데이터 -> 연산자)

주어진 중위식 : A * (B + C) / D - E

(1) A * (B + C) / D - E

- > A * BC + / D - E

(2) A * BC + / D - E

-> ABC +* / D - E

(3) ABC + * / D - E

-> ABC + * D / - E

(4) ABC + * D / - E

-> ABC + * D / E - (후위식)

 

29. 중위 표 기법(Infix)의 수식 (A+B)*C+(D+E)을 후위 표 기법으로(Postfix) 올바르게 표기한 것은?

1. AB+CDE*++

2. AB+C*DE++

3.+AB*C+DE+

4.+*+ABC+DE

 

주어진 중위 표기 수식:
(A + B) * C + (D + E)

이 수식을 후위 표기(Postfix, Reverse Polish Notation)로 변환하면 다음과 같은 순서로 변환됩니다.

변환 과정:

1단계: 괄호 안 먼저 처리

(A + B) → 후위로 AB+

(D + E) → 후위로 DE+

2단계: 가운데 곱셈 처리

중위로: (A + B) * C
후위로: AB+와 C를 곱하면 → AB+C*

3단계: 마지막으로 전체 덧셈

중위로: ((A + B) * C) + (D + E)
지금까지 구한 후위표기:

• 좌측: AB+C*
• 우측: DE+

이 두 항을 더하므로 → AB+C*DE+ +

즉, AB+C*DE++

 

정답:

2. AB+C*DE++

 

✅ 선형 구조 (Linear Structure)

데이터가 일렬로 나열되어 있으며, 순차적으로 접근 가능한 구조입니다.

🔹 종류

자료구조	설명
배열 (Array)	고정된 크기의 연속된 메모리 공간에 데이터를 저장
연결 리스트 (Linked List)	노드들이 포인터를 통해 순차적으로 연결됨
스택 (Stack)	LIFO 구조, 한 쪽 끝에서만 삽입/삭제
큐 (Queue)	FIFO 구조, 앞에서 삭제하고 뒤에서 삽입
덱 (Deque)	양쪽에서 삽입과 삭제가 가능한 큐

 

✅ 비선형 구조 (Non-Linear Structure)

데이터가 계층적 또는 연결된 방식으로 구성되어 있으며, 노드 간 관계가 복잡한 구조입니다.

🔹 종류

자료구조	설명
트리 (Tree)	계층적 구조, 루트 노드에서 시작하여 자식 노드로 분기
이진 트리 (Binary Tree)	각 노드가 최대 두 개의 자식을 가짐
이진 탐색 트리 (BST)	왼쪽 자식은 작고, 오른쪽 자식은 큰 값을 가짐
힙 (Heap)	최대/최소 값을 빠르게 찾기 위한 완전 이진 트리
그래프 (Graph)	정점(Vertex)과 간선(Edge)으로 구성된 구조, 복잡한 관계 표현에 적합

🔎 요약 비교

구분	선형 구조	비선형 구조
형태	일렬로 나열	계층적 / 연결됨
접근 방식	순차적	비순차적, 다양함
예시	배열, 스택, 큐	트리, 그래프

 

 

 

블랙박스 검사 기법 (Black Box Testing)

소프트웨어의 내부 구조를 보지 않고, 주어진 입력값과 출력값을 중심으로 검사하는 방법입니다. 사용자의 입장에서 프로그램이 원하는 대로 작동하는지 확인하는 데 주로 사용됩니다.

🔹 주요 기법

기법	설명
동치 분할 검사 (Equivalence Partitioning)	입력 데이터를 **유효/무효 그룹(등가 클래스)**으로 나누고 각 그룹에서 대표값을 선택해 테스트함.
경계값 분석 (Boundary Value Analysis)	오류가 자주 발생하는 경계값 근처의 데이터를 중심으로 테스트함.
결정 테이블 검사 (Decision Table Testing)	다양한 조건과 그에 따른 동작을 표 형식으로 정리해 테스트함.
상태 전이 검사 (State Transition Testing)	시스템의 상태 변화(이벤트/조건/행위)를 모델링해 테스트함.
원인-결과 그래프 기법 (Cause-Effect Graphing)	**입력(원인)**과 출력(결과) 간의 관계를 논리적으로 표현하고 이를 기반으로 테스트 케이스를 설계함.
사용 기반 테스트 (Use Case Testing)	실제 사용자 관점에서 시나리오 기반 테스트를 설계함.

 

화이트박스 검사 기법 (White Box Testing)

소프트웨어의 내부 로직과 흐름을 분석하여 테스트 케이스를 설계하는 방식입니다. 개발자 관점의 테스트로, 코드의 모든 경로, 조건, 루프 등을 검사합니다.

🔹 주요 기법

기법	설명
문장 검사 (Statement Coverage)	코드의 모든 문장이 최소 한 번은 실행되도록 테스트
분기 검사 (Branch Coverage)	모든 **분기점(조건의 true/false)**이 실행되도록 테스트
조건 검사 (Condition Coverage)	각 개별 조건이 true/false 모두 발생하도록 테스트
결합 조건 검사 (Condition Combination Coverage)	여러 조건의 조합에 대한 결과를 테스트
기초 경로 검사 (Basis Path Testing)	제어 흐름 그래프를 통해 독립적인 실행 경로를 식별하고 테스트
루프 검사 (Loop Testing)	반복문의 다양한 실행 횟수(0회, 1회, 여러 회)에 대해 테스트

🔎 요약 비교

항목	블랙박스 검사	화이트박스 검사
접근 방식	외부 동작 위주	내부 코드 위주
설계 기준	요구사항 명세서	프로그램 소스코드
사용 주체	테스트 엔지니어	개발자
기법 예시	경계값 분석, 동치 분할	조건 검사, 기초 경로 검사

 

소프트웨어 품질 목표 (ISO 9126 기준 기준 설명)

1. 기능성 (Functionality)

소프트웨어가 요구한 기능을 정확하게 수행하는 능력

• 정확성 (Correctness): 요구사항을 충족시키는가?
• 적합성 (Suitability): 주어진 작업에 적합한 기능을 제공하는가?
• 상호 운용성 (Interoperability): 다른 시스템과 잘 작동하는가?
• 보안성/무결성 (Security/Integrity): 데이터 접근 권한이 통제되고 보호되는가?

2. 신뢰성 (Reliability)

소프트웨어가 오류 없이 안정적으로 동작하는 능력

• 성숙도 (Maturity): 오류 발생 가능성이 낮은가?
• 고장 허용성 (Fault Tolerance): 장애 발생 시에도 기능을 유지할 수 있는가?
• 복구성 (Recoverability): 오류 발생 후 복구가 가능한가?

3. 사용성 (Usability)

사용자가 쉽게 배우고 사용할 수 있는지에 대한 정도

• 이해성 (Understandability): 쉽게 이해할 수 있는가?
• 학습성 (Learnability): 빠르게 배울 수 있는가?
• 조작성 (Operability): 쉽게 사용할 수 있는가?
• 일관성 (Consistency): 인터페이스가 일관적인가?

4. 효율성 (Efficiency)

자원을 얼마나 효율적으로 사용하는가

• 시간 효율성 (Time Behavior): 반응 속도, 처리 속도
• 자원 효율성 (Resource Utilization): CPU, 메모리, 네트워크 자원 활용 정도

5. 유지보수성 (Maintainability)

소프트웨어를 쉽게 수정, 개선, 확장할 수 있는 능력

• 분석성 (Analyzability): 오류를 쉽게 분석할 수 있는가?
• 변경성 (Changeability): 코드를 쉽게 수정할 수 있는가?
• 안정성 (Stability): 변경해도 다른 부분에 영향이 적은가?
• 시험성 (Testability): 테스트를 쉽게 수행할 수 있는가?

6. 이식성 (Portability)

다양한 환경에서 소프트웨어를 쉽게 옮겨 사용할 수 있는가

• 적응성 (Adaptability): 다른 환경에 쉽게 적용되는가?
• 설치성 (Installability): 쉽게 설치 가능한가?
• 호환성 (Co-existence): 다른 소프트웨어와 함께 작동 가능한가?
• 대체성 (Replaceability): 유사 소프트웨어로 쉽게 교체 가능한가?

✅ ISO/IEC 25010 (2011 개정 모델) 추가 항목

이후 개정된 모델에는 다음 항목이 추가 또는 강조되었습니다:

• 보안성 (Security): 데이터 보호, 인증, 접근 제어 등
• 기능적 적합성 (Functional Suitability): 요구 기능을 얼마나 잘 수행하는가
• 호환성 (Compatibility): 다른 시스템과의 통합 가능성

📌 요약표

대분류	세부 항목 예시
기능성	정확성, 보안성, 상호운용성
신뢰성	오류 허용, 복구성
사용성	학습성, 조작성, 일관성
효율성	시간/자원 효율
유지보수성	변경성, 안정성, 분석성
이식성	적응성, 설치성, 대체성
(25010 추가) 보안성	인증, 인가, 기밀성, 무결성
(25010 추가) 호환성	다양한 플랫폼/환경에서 동작 여부

 

37. 다음 그래프에서 정점 A를 선택하여 깊이우선탐색(DFS)으로 운행한 결과는?

1. ABECDFG
2. ABECFDG
3. ABCDEFG
4. ABEFGCD

 

<문제 해설>
깊이 우선 탐색(Depth First Search)는 이름 그대로 최대한 깊이 탐색한 이후 더이상 탐색할 것이 없다면 그 이전으로 돌아가 탐색을 이어가는 것입니다. 탐색을 하고 있는 분기에서 완벽하게 탐색을 한 이후 다른 분기를 탐색하는 방법입니다.
고로 A-B-E-F-G까지 탐색한 이후 더이상 탐색할 것이 없기 때문에 이전으로 돌아가 C-D를 마저 탐색해줍니다.

 

22. 다음과 같이 레코드가 구성되어 있을 때, 이진 검색 방법으로 14를 찾을 경우 비교되는 횟수는?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1. 2
2. 3
3. 4
4. 5

📌 문제 요약:

• 데이터: 오름차순 정렬된 15개의 원소
  1, 2, 3, ..., 15
• 찾을 값: 14
• 질문: 이진 검색으로 14를 찾을 때 비교되는 횟수는?

📘 이진 검색 개념:

이진 검색은 중간 값을 기준으로 왼쪽/오른쪽 절반을 제거하며 진행됩니다.
비교 횟수는 찾고자 하는 값이 어디에 있느냐에 따라 달라집니다.

🔍 실제 비교 과정:

Step 1:

• 범위: 1~15
• 중간 인덱스 = (1 + 15) / 2 = 8, 값 = 8
• 14 > 8 → 오른쪽으로 이동
  ➡ 비교 1회

Step 2:

• 범위: 9~15
• 중간 인덱스 = (9 + 15) / 2 = 12, 값 = 12
• 14 > 12 → 오른쪽으로 이동
  ➡ 비교 2회

Step 3:

• 범위: 13~15
• 중간 인덱스 = (13 + 15) // 2 = 14, 값 = 14
• 찾음!
  ➡ 비교 3회

33. 다음은 인스펙션(Inspection) 과정을 표현한 것이다. (가)~(마)에 들어갈 말을 보기에서 찾아 바르게 연결한 것은?

1. (가) - ㉡, (나) - ㉢
2. (나) - ㉠, (다) - ㉢
3. (다) - ㉢, (라) - ㉤
4. (라) - ㉣, (마) - ㉢

 

주어진 단계들을 인스펙션(Inspection) 프로세스의 순서에 맞춰 정리하면 다음과 같습니다

 

 

 

1. 계획(Planning)
인스펙션을 시작하기 전에 목표, 범위, 참여자 등을 설정하는 단계입니다.

 

2. 사전 교육(Pre-Inspection Training)
인스펙션에 참여할 사람들에게 검토 대상, 절차, 목표 등을 사전 교육하는 단계입니다. (이 교육이 필요할 경우에 해당합니다.)

 

3. 준비(Preparation)
인스펙션을 위해 필요한 자료 준비, 문서나 코드 등을 배포하고 준비하는 단계입니다.

 

4. 인스펙션 회의(Inspection Meeting)
실제로 코드나 문서를 검토하고 결함을 찾는 단계입니다. 인스펙션 팀이 모여서 각자 발견한 문제점을 논의합니다.

 

5. 수정(Correction)
검토 과정에서 발견된 문제를 수정하는 단계입니다.

 

6. 후속 조치(Follow-up)
수정 사항에 대해 후속 검토를 진행하고, 수정된 내용이 제대로 반영되었는지 확인하는 단계입니다.

 

인스펙션(Inspection)

인스펙션(Inspection) 과정은 소프트웨어 개발에서 품질을 보장하기 위한 정적 검토(Static Review) 방법 중 하나로, 주로 소스 코드나 문서의 결함을 찾아내기 위해 팀원들이 직접 서면으로 작성된 문서나 코드를 검토하는 과정을 의미합니다.

인스펙션 과정의 주요 특징:

• 자동화가 아닌 수동적 검토: 인스펙션은 코드나 문서를 사람이 직접 검토하는 방법으로, 오류나 결함을 찾아내기 위한 수단입니다.
• 목표: 주로 결함을 예방하고, 프로세스를 개선하기 위해 사용됩니다.
• 형식적인 검토 과정: 인스펙션은 보통 체계적이고 표준화된 절차를 따르며, 검토를 수행하는 사람들이 주어진 문서나 코드에 대해 철저히 검토합니다.

인스펙션 과정의 단계:

인스펙션은 보통 다섯 가지 단계로 이루어집니다:

1. 준비(Planning)

• 목표: 인스펙션을 시작하기 전에 목표 설정과 검토 범위를 정의합니다.
• 활동:
  • 인스펙션을 진행할 문서나 코드를 선정합니다.
  • 인스펙션의 일정과 참여자를 결정합니다.
  • 검토할 대상과 검토 기준을 명확히 정의합니다.

2. 검토(Inspection)

• 목표: 각 팀원이 선정된 문서나 코드에서 결함을 찾는 작업을 진행합니다.
• 활동:
  • 각 참가자는 코드나 문서를 사전에 읽고 준비합니다.
  • 인스펙션 회의에서 각 사람은 발견한 문제점이나 결함을 설명합니다.
  • 결함을 분류하고 우선순위를 정합니다.

3. 토의(Discussion)

• 목표: 검토 과정에서 나온 문제점에 대해 깊이 있는 토론을 합니다.
• 활동:
  • 각 문제점에 대해 토의하여 문제의 원인을 파악하고, 해결 방법을 제시합니다.
  • 팀원들이 각자의 의견을 나누며, 다양한 관점에서 결함을 분석합니다.

4. 결정(Decision)

• 목표: 각 결함에 대해 수정 여부와 수정 방법을 결정합니다.
• 활동:
  • 발견된 결함이 중요한지, 아닌지에 대해 논의하고, 수정할 부분을 결정합니다.
  • 수정이 필요한 부분은 구체적인 수정 계획을 수립합니다.

5. 후속 작업(Follow-up)

• 목표: 인스펙션 이후에 결정된 수정 사항을 실제로 반영하고, 수정된 사항을 검토합니다.
• 활동:
  • 수정된 사항에 대해 후속 검토를 진행합니다.
  • 수정이 완료된 후, 필요한 경우 다시 인스펙션을 진행할 수 있습니다.

인스펙션의 장점:

• 초기 단계에서 결함 발견: 결함을 개발 초기 단계에서 찾아내므로, 수정 비용이 적습니다.
• 문서화된 피드백: 검토 내용이 기록으로 남아 향후 참고할 수 있습니다.
• 개발 품질 향상: 팀 간의 협업을 통해 개발 품질을 향상시킬 수 있습니다.
• 팀원들의 기술 향상: 다양한 관점에서 코드나 문서를 검토하면서 팀원들이 더 나은 코딩 표준을 익힐 수 있습니다.

 

27. 다음 그래프의 인접 행렬(Adjacency Matrix) 표현 시 옳은 것은?

 

[관계도를 그려보면]

1 - 3

1 - 2

2 - 3

3 - 1

 

[표로 그려보면]

	1	2	3
1	0	1	1
2	0	0	1
3	1	0	0

 

결합도(Coupling)

 결합도(Coupling)는 모듈 간의 의존 관계를 나타내며, 모듈의 독립성 정도를 측정하는 지표입니다. 결합도가 낮을수록 모듈 간 의존성이 적고, 더 독립적으로 동작할 수 있어 재사용성과 유지보수성이 향상됩니다.

결합도의 종류는 여러 가지가 있으며, 결합도가 높은 순서대로 설명드리겠습니다. 낮은 결합도를 목표로 하는 것이 중요합니다.

결합도 우선순위 (높은 결합도에서 낮은 결합도 순)

1. 내용 결합도 (Content Coupling)
   • 설명: 두 모듈이 서로의 내부 구현에 직접적으로 접근하거나, 내부 데이터를 수정하는 경우입니다. 예를 들어, 한 모듈이 다른 모듈의 지역 변수를 변경하거나 함수의 내용을 직접 호출하는 경우입니다.
   • 문제점: 내용 결합도가 높으면 모듈 간 독립성이 극도로 낮아집니다. 이로 인해 한 모듈의 수정이 다른 모듈에 미치는 영향이 크고, 재사용성도 떨어집니다.
   • 우선순위: 최소화해야 할 결합도.
2. 제어 결합도 (Control Coupling)
   • 설명: 한 모듈이 다른 모듈에 제어 흐름을 전달하는 경우입니다. 예를 들어, 한 모듈이 다른 모듈에게 어떤 처리를 수행할지에 대한 정보를 전달하는 경우입니다.
   • 문제점: 제어 결합도는 모듈 간의 의존성이 있지만, 내용 결합도보다는 적은 의존성을 가집니다. 그러나, 여전히 불필요한 제어 흐름 전달이 있으면 모듈의 독립성이 떨어집니다.
   • 우선순위: 가능한 한 최소화.
3. 공통 결합도 (Common Coupling)
   • 설명: 두 모듈이 동일한 전역 데이터를 공유하는 경우입니다. 예를 들어, 두 모듈이 동일한 전역 변수를 읽거나 수정하는 경우입니다.
   • 문제점: 공통 결합도가 높으면 데이터를 공유하는 과정에서 예기치 않은 오류가 발생할 수 있으며, 유지보수성도 저하됩니다. 그러나 내용 결합도보다는 의존성이 낮습니다.
   • 우선순위: 가능한 한 최소화.
4. 스탬프 결합도 (Stamp Coupling)
   • 설명: 한 모듈이 다른 모듈에 구조체나 배열을 전달하는 경우입니다. 예를 들어, 하나의 구조체를 모듈에 전달하여 여러 멤버 변수를 함께 사용하는 경우입니다.
   • 문제점: 스탬프 결합도는 데이터의 일부만 필요한 경우에도 전체 데이터를 전달해야 하므로 불필요한 데이터 전달이 이루어지게 됩니다. 그러나, 내용 결합도보다는 의존성이 적습니다.
   • 우선순위: 가능한 한 최소화.
5. 데이터 결합도 (Data Coupling)
   • 설명: 두 모듈이 데이터를 단순히 전달하는 경우로, 하나의 모듈이 다른 모듈에 데이터를 전달할 때 최소한의 정보만 전달하는 방식입니다. 예를 들어, 함수 간에 파라미터를 넘기는 경우입니다.
   • 문제점: 데이터 결합도는 낮은 결합도로, 모듈 간 의존성이 적고 독립성을 유지할 수 있습니다. 모듈 간 인터페이스가 명확하고, 필요한 정보만 전달되므로 재사용성이 높습니다.
   • 우선순위: 가장 이상적인 결합도.
6. 의존 결합도 (Message Coupling)
   • 설명: 두 모듈이 서로 메시지를 전달하는 형식으로 결합되는 경우입니다. 이는 메시지를 주고받는 방식으로 의존성을 최소화하는 결합도입니다.
   • 문제점: 매우 낮은 의존성을 갖고 있으며, 결합도가 거의 없는 상태에 가까운 이상적인 형태입니다.
   • 우선순위: 가장 이상적이며, 최선의 결합도.

결합도 순위 요약:

1. 내용 결합도 (Content Coupling) → 최소화
2. 제어 결합도 (Control Coupling) → 최소화
3. 공통 결합도 (Common Coupling) → 최소화
4. 스탬프 결합도 (Stamp Coupling) → 가능한 최소화
5. 데이터 결합도 (Data Coupling) → 이상적, 최대화
6. 의존 결합도 (Message Coupling) → 최선, 최대화

결론:

 모듈의 재사용성을 높이기 위해서는 내용 결합도(Content Coupling), 제어 결합도(Control Coupling), 공통 결합도(Common Coupling), 스탬프 결합도(Stamp Coupling) 등을 최소화하는 것이 중요합니다. 데이터 결합도(Data Coupling) 와 의존 결합도(Message Coupling) 는 낮은 결합도를 유지하면서 최적화해야 할 목표입니다.

 

응집도(Cohesion)

 응집력(Cohesion)은 모듈 내의 구성 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내며, 응집력이 강할수록 해당 모듈은 하나의 명확한 책임을 가지고 효율적으로 동작합니다. 응집력은 강한 것부터 약한 것까지 여러 수준으로 나눌 수 있으며, 각 수준의 특징은 다음과 같습니다.

응집력의 강한 것부터 약한 순서:

1. 기능적 응집력 (Functional Cohesion)
   • 설명: 모듈이 단 하나의 명확한 작업을 수행하는 경우입니다. 모든 작업이 하나의 목표를 위해 수행됩니다.
   • 예시: "파일 읽기"라는 기능을 수행하는 모듈. 이 모듈은 오직 파일 읽기만 수행합니다.
   • 특징: 가장 강한 응집력을 가집니다. 코드의 이해와 유지보수가 쉬움.
2. 순차적 응집력 (Sequential Cohesion)
   • 설명: 모듈 내의 작업들이 순차적으로 처리되며, 하나의 작업이 다른 작업의 입력을 제공하는 경우입니다.
   • 예시: "파일 읽기 → 데이터 처리 → 데이터 저장"처럼, 각각의 작업이 순차적으로 이어지는 경우입니다.
   • 특징: 작업들이 논리적으로 연결되어 있지만, 반드시 하나의 기능을 수행하는 것은 아님. 여전히 응집력이 꽤 강함.
3. 절차적 응집력 (Procedural Cohesion)
   • 설명: 모듈 내의 여러 작업들이 논리적으로 관련이 있지만, 반드시 순차적으로 처리될 필요는 없는 경우입니다.
   • 예시: "사용자 입력 처리"와 같은 모듈이 여러 단계를 순차적으로 거쳐 처리하지만, 각 단계의 처리가 독립적일 수 있습니다.
   • 특징: 작업들이 하나의 절차적 흐름에 따라 구성되지만, 응집력은 기능적 응집력보다는 약함.
4. 논리적 응집력 (Logical Cohesion)
   • 설명: 모듈이 여러 관련 없는 작업들을 논리적으로 묶어 놓은 경우입니다. 이러한 작업들은 논리적으로는 관련이 있을 수 있지만, 실제로는 매우 다른 기능일 수 있습니다.
   • 예시: "입력 처리" 모듈이 숫자 입력, 문자 입력, 날짜 입력 등 여러 종류의 입력을 처리하는 경우입니다.
   • 특징: 작업들이 논리적으로 묶여 있지만, 실제로는 서로 다른 작업을 처리하는 경우가 많아 응집력은 중간 정도입니다.
5. 우연적 응집력 (Coincidental Cohesion)
   • 설명: 모듈 내의 작업들이 아무런 관계 없이 임의로 묶여 있는 경우입니다. 이는 응집력 중 가장 약한 형태입니다.
   • 예시: "파일 읽기", "문자열 처리", "디스크 공간 확인" 등이 모듈 내에서 서로 관련 없이 처리되는 경우입니다.
   • 특징: 응집력이 매우 약하고, 모듈 간의 독립성이 떨어져 유지보수와 확장이 어려워집니다.

응집력 순서 (강한 것부터 약한 것까지):

1. 기능적 응집력 (Functional Cohesion)
2. 순차적 응집력 (Sequential Cohesion)
3. 절차적 응집력 (Procedural Cohesion)
4. 논리적 응집력 (Logical Cohesion)
5. 우연적 응집력 (Coincidental Cohesion)

결론:

 응집력이 강할수록 모듈은 하나의 명확한 목적을 가지고 효율적으로 작업을 수행할 수 있습니다. 따라서 소프트웨어 설계에서는 가능하면 기능적 응집력 (Functional Cohesion) 을 목표로 해야 하며, 응집력을 강하게 유지하는 것이 유지보수성과 재사용성을 높이는 데 중요한 역할을 합니다.

 

36. 다음이 설명하는 테스트 관련 용어는?

• 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이다.
• 테스트의 정확성과 신뢰성을 향상시키는 역할을 수행한다.

1. 테스트 커버리지 

2. 테스트 시나리오

3. 테스트 드라이버 

4. 테스트 스텁

 

✅ 해설:

문제에서 설명하는 내용을 하나씩 분석해보면 다음과 같습니다:

• 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이다.
→ 이는 소프트웨어 코드나 요구사항 중 얼마나 많은 부분이 테스트되었는지를 측정하는 개념입니다.
→ 이런 기준은 "테스트 커버리지" 라고 부릅니다.

• 테스트의 정확성과 신뢰성을 향상시키는 역할을 수행한다.
→ 테스트 커버리지가 높다는 것은 더 많은 코드나 기능이 테스트되었다는 의미이며, 따라서 테스트의 정확성과 신뢰성이 높아집니다.

보기별 설명:

1. 테스트 커버리지 (Test Coverage) ✅
   • 테스트 케이스가 소프트웨어의 코드, 조건, 분기 등을 얼마나 많이 커버하는지 측정하는 지표
   • 테스트의 품질과 신뢰도를 판단하는 데 사용
2. 테스트 시나리오 (Test Scenario)
   • 테스트할 기능이나 상황을 설명한 문서
   • "무엇을 테스트할 것인가"에 대한 서술
   • → 커버리지를 측정하는 기준은 아님
3. 테스트 드라이버 (Test Driver)
   • 상향식 통합 테스트에서 하위 모듈을 테스트하기 위해 임시로 만든 상위 모듈
   • → 테스트 범위를 측정하는 것과는 무관
4. 테스트 스텁 (Test Stub)
   • 하향식 통합 테스트에서 상위 모듈을 테스트하기 위해 임시로 만든 하위 모듈
   • → 이것도 테스트 도구일 뿐, 커버리지를 측정하는 개념은 아님

✅ 결론:

테스트 범위를 측정하고, 테스트의 신뢰성을 높이는 품질 기준은
→ 1번. 테스트 커버리지입니다.

 

39. 다음 중 확인 시험(Validation Test)과 거리가 먼 것은?

1. 알파(Alpha) 테스트
2. 베타(Beta) 테스트
3. 블랙박스(Black Box) 테스트
4. 화이트박스(White Box) 테스트

 

정답: 4. 화이트박스(White Box) 테스트

✅ 해설:

 확인 시험(Validation Test) 은 소프트웨어가 사용자의 요구사항을 만족하는지를 검증하는 과정입니다. 즉, "제대로 만든 것인가?(Did we build the right product?)" 를 확인하는 시험입니다. 주로 외부 동작(기능) 중심으로 테스트하며, 사용자의 입장에서 수행됩니다.

보기별 설명:

1. 알파(Alpha) 테스트
   • 개발자가 아닌 독립적인 테스터들이 조직 내부에서 수행
   • 사용자의 입장에서 기능을 테스트 → Validation에 해당
2. 베타(Beta) 테스트
   • 최종 사용자들이 실제 환경에서 사용하는 테스트
   • 실제 사용자를 기반으로 피드백을 수집 → Validation에 해당
3. 블랙박스(Black Box) 테스트
   • 내부 구조를 고려하지 않고, 입력과 출력만 확인
   • 기능 요구사항이 제대로 작동하는지 확인 → Validation에 해당
4. 화이트박스(White Box) 테스트
   • 프로그램의 내부 로직, 코드 흐름 등을 기반으로 테스트
   • 개발자 시각에서의 Verification 테스트
   • → Validation(사용자 요구 검증)과는 거리가 멈

SPICE 모델의 레벨

레벨 5 최적(optimizing) 단계
정의된 프로세스와 표준 프로세스가 지속적으로 개선되는 단계이다.

레벨 4 예측(predictable) 단계
표준 프로세스 능력에 대하여 정량적인 이해와 성능이 예측되는 단계이다.

레벨 3 확립(established) 단계
표준 프로세스를 사용하여 계획되고 관리된 단계이다.

레벨 2 관리(managed) 단계
프로세스가 정해진 절차에 따라 이루어져 산출물을 내며, 모든 작업이 계획되고 추적되는 단계이다.

레벨 1 수행(performed) 단계
해당 프로세스의 목적은 달성하지만 계획되거나 추적되지 않은 단계이다.

레벨 0 불완전(incomplete) 단계
프로세스가 구현되지 않거나 프로세스 목적을 달성하지 못한 단계이다.

 

 

1. Putnam의 법칙 (Putnam's Law)

• 소프트웨어 개발 노력과 개발 기간 간의 상관관계를 설명한 법칙
• 개발에 필요한 **노력(인월)**과 개발 기간은 반비례 관계
• 하지만 무작정 인력을 늘린다고 기간이 줄어드는 건 아니라는 것을 수학적으로 모델링

 

2. Mayer의 법칙 (Mayer's Law)

• 사용자 인터페이스 설계와 관련된 법칙으로 알려져 있으며,
• 이름 오류일 가능성도 있습니다.
  일반적인 프로젝트 관리 관련 법칙에는 Mayer의 법칙이라는 개념은 널리 통용되지 않습니다.

3. Brooks의 법칙 (Brooks’s Law) 

• "늦어진 프로젝트에 사람을 더 투입하면 프로젝트는 더 늦어진다."
• Fred Brooks가 저서 『The Mythical Man-Month』에서 제안
• 이유:
  • 신규 인원 교육에 시간 소모
  • 커뮤니케이션 복잡성 증가
  • 기존 작업 흐름

4. Boehm의 법칙 (Boehm's Law)

• Barry Boehm이 제안한 소프트웨어 비용과 품질 관련 법칙
• 품질 향상과 관련된 투자와 노력에 대한 통찰 제공
• 소프트웨어의 결함은 개발 초기에 발견할수록 수정 비용이 낮다는 결함 비용 상승 곡선(Cost of Change Curve)과도 관련