[7급 국가직 소프트웨어공학] 25년 1회차 기출문제 정답·해설 페이지

보기 중 응집도가 가장 높은 것은 기능적 응집도이다.
응집도 강도는 기능적 > 순차적 > 교환(통신)적 > 절차적 > 시간적 > 논리적 > 우연적 순이며, 기능적 응집도는 모듈 내부 요소가 단일 기능 수행을 위해 모인 경우다.
절차적 응집도: 정해진 수행 순서에 따라 묶였을 뿐이라 기능적보다 약하다.
시간적 응집도: 초기화처럼 같은 시점에 실행된다는 이유로 묶인 경우로 더 약하다.
논리적 응집도: 유사한 성격의 처리를 한 모듈에 모아 플래그로 골라 쓰는 형태로, 우연적 다음으로 약하다.

경곗값 분석 결과는 －1, 0, 1, 119, 120, 121이다.
경곗값 분석은 유효 범위의 경계와 그 바로 안팎 값을 시험한다. 하한 0의 바로 아래·경계·바로 위(－1, 0, 1), 상한 120의 바로 아래·경계·바로 위(119, 120, 121)를 고른다.
0, 60, 120: 범위 밖 값이 없고 60은 경계와 무관한 대표값이라 동등 분할에 가깝다.
－10, 0, 120, 130: 경계 바로 옆이 아닌 임의의 범위 밖 값을 써서 경계 인접 오류를 잡지 못한다.
0, 1, 2, 118, 119, 120: 모두 유효 범위 안의 값이라 무효 경계값(－1, 121)이 빠졌다.

바른 연결은 (가) E-R 다이어그램, (나) 자료 흐름도, (다) 유스케이스 다이어그램이다.
정보공학 방법론은 데이터 중심이라 개체·관계를 E-R 다이어그램으로 표현하고, 구조적 방법론은 기능(프로세스) 중심이라 자료 흐름도로 분석한다. 객체지향 방법론은 UML을 쓰며 요구사항을 유스케이스 다이어그램으로 모델링한다.
A B C 연결: 정보공학에 유스케이스, 구조적에 E-R, 객체지향에 자료 흐름도를 붙여 세 방법론이 모두 어긋난다.
A C B 연결: 구조적-자료 흐름도는 맞지만 정보공학과 객체지향의 도구가 서로 뒤바뀌었다.
C B A 연결: 객체지향-유스케이스는 맞지만 정보공학과 구조적 방법론의 도구가 서로 뒤바뀌었다.

조건 커버리지를 만족하는 집합은 {(a=6, b=0), (a=3, b=－1)}이다.
조건 커버리지는 각 개별 조건(a>5, b==0, a==3, b<0)이 참과 거짓을 모두 한 번 이상 가져야 한다. (6, 0)은 a>5·b==0이 참, a==3·b<0이 거짓이고, (3, －1)은 정확히 반대라 네 조건 모두 양쪽 값을 얻는다.
{(2, 0), (2, 1)}: a>5와 a==3, b<0이 한 번도 참이 되지 않는다.
{(3, 0), (4, －2)}: a>5가 한 번도 참이 되지 않는다.
{(6, 0), (2, 1)}: 두 번째 if의 a==3과 b<0이 모두 참이 되지 않는다.

V 모델에서 (가)는 아키텍처 설계, (나)는 모듈 설계, (다)는 통합 테스트, (라)는 시스템 테스트이므로 C, A, D, B 순서의 연결이 옳다.
V 모델은 왼쪽 개발 단계와 오른쪽 검증 단계가 같은 높이끼리 짝을 이룬다. 그림에서 모듈 설계↔단위 테스트, 아키텍처 설계↔통합 테스트, 요구분석↔시스템 테스트로 대응하고 마지막에 인수 및 설치가 온다. 설계는 큰 단위에서 작은 단위로 내려가고, 검증은 작은 단위에서 큰 단위로 올라간다.
A B C D 연결: 요구분석 바로 다음은 전체 구조를 정하는 아키텍처 설계이며, 시스템 테스트는 왼쪽 설계 자리에 올 수 없다.
A C B D 연결: 모듈 설계와 아키텍처 설계의 순서가 뒤바뀌었고, 시스템 테스트가 통합 테스트보다 먼저 온다.
C A B D 연결: 단위 테스트 → 통합 테스트 → 시스템 테스트 순으로 검증 범위가 넓어지므로 시스템 테스트가 통합 테스트보다 앞설 수 없다.

(가)는 Study, (나)는 Study, (다)는 Lecture이다.
클래스 다이어그램에서 속이 빈 삼각형 화살표는 일반화(상속) 관계이며, 화살표가 가리키는 위쪽 (가)가 부모 클래스, 아래쪽 (다)가 자식 클래스이다. 코드에서 Study는 아무것도 상속하지 않으므로 부모이고, Lecture가 extends 로 Study를 상속하므로 (나)에도 Study가 들어간다.
Study, Lecture, Lecture 연결: (나)가 Lecture이면 클래스가 자기 자신을 상속하게 되어 불가능하다.
Lecture, Study, Study 연결: 부모와 자식이 뒤바뀐 것으로, 상속받는 쪽은 extends 를 쓴 Lecture이다.
Lecture, Lecture, Study 연결: 자기 자신 상속이 되고 부모·자식도 뒤바뀌었다.

모든 문장을 지나는 경로는 5행 다음 6행 → 7행 → 4행을 거쳐 8행으로 가는 것이다.
문장 커버리지를 만족하려면 경로에 6행(sum += i)이 반드시 포함되어야 한다. 제어 흐름상 5행의 if가 참이면 6행, 이어 7행, 반복문 끝에서 while 조건(4행)으로 되돌아가고 거짓이면 8행으로 나간다.
6행 → 7행 → 5행: 7행 다음에는 while 조건 검사(4행)로 가야 하며 5행으로 바로 갈 수 없다.
7행 → 4행 → 6행: 4행에서 6행으로 가는 흐름이 없고, 반드시 5행의 if를 거쳐야 한다.
7행 → 4행 → 7행: 4행에서 7행으로 바로 갈 수 없으며 6행이 실행되지 않아 문장 커버리지도 충족하지 못한다.

옳지 않은 설명은 개방 폐쇄 원칙을 거꾸로 서술한 것이다.
개방 폐쇄 원칙은 모듈이 확장에는 열려 있고 수정에는 닫혀 있어야 한다는 원칙으로, 기존 코드를 고치지 않고 기능을 추가할 수 있게 설계하라는 뜻이다.
단일 책임 원칙: 클래스는 하나의 책임만 가져 변경 이유가 하나뿐이어야 한다는 설명은 옳다.
리스코프 대체 원칙: 상위 타입 객체 자리에 하위 타입 객체를 넣어도 프로그램이 올바르게 동작해야 한다는 설명은 옳다.
의존 관계 역전 원칙: 구체 클래스가 아닌 추상(인터페이스)에 의존해야 한다는 설명은 옳다.

클래스 내 메소드 복잡도의 합으로 정의되는 척도는 WMC(Weighted Methods per Class)이다.
WMC는 클래스에 정의된 각 메소드의 복잡도를 모두 더한 값으로, 값이 클수록 클래스 구현·유지보수 노력이 크고 재사용성이 낮다고 본다.
NOC: 클래스의 직계 하위 클래스 수를 센다.
CBO: 해당 클래스와 결합된 다른 클래스의 수를 센다.
LCOM: 메소드들이 인스턴스 변수를 공유하지 않는 정도, 즉 응집도 결여를 잰다.

시스템의 가용성은 0.8이다.
가용성은 전체 시간 중 가동 시간의 비율이다.
$A = \dfrac{\mathrm{Up}}{\mathrm{Up} + \mathrm{Down}}$
가동 시간 합은 $12 + 9 + 10 + 5 = 36\,\mathrm{h}$, 고장 시간 합은 $4 + 2 + 3 = 9\,\mathrm{h}$이다.
$A = \dfrac{36}{36 + 9} = \dfrac{36}{45} = 0.8$
0.2는 고장 시간 비율(9/45)로, 가용성의 반대 개념인 비가용 비율이다.
0.25는 고장 시간을 가동 시간으로 나눈 값(9/36)이라 가용성 정의와 다르다.
0.9는 가동·고장 시간을 잘못 합산해야 나오는 값으로 표의 수치와 맞지 않는다.

적용된 기법은 리팩토링이다.
프로그램의 외부 동작(출력 결과)은 그대로 두고, 조건 출력 부분을 별도 메소드로 뽑아내는 메소드 추출로 내부 구조만 개선했다.
재사용: 이미 만들어진 컴포넌트·코드를 다른 곳에서 다시 활용하는 것으로, 구조 개선과는 다르다.
순공학: 요구·설계에서 출발해 구현으로 내려가는 일반적인 개발 방향을 말한다.
역공학: 기존 코드에서 설계·명세 같은 상위 수준 정보를 추출하는 활동이다.

필요한 최소 기간은 10개월이다.
월 생산량 = 초급 4명 × 1,000 + 중급 2명 × 1,500
$4 \times 1000 + 2 \times 1500 = 7000\,\mathrm{LOC/month}$
기간 = 총 LOC ÷ 월 생산량
$\dfrac{65000}{7000} \approx 9.29$
9개월로는 63,000 LOC만 개발되어 부족하므로 올림하여 10개월이 필요하다.
7개월·8개월: 각각 49,000·56,000 LOC로 목표에 크게 못 미친다.
9개월: 63,000 LOC로 2,000 LOC가 남는다.

설명에 해당하는 활동은 형상 감사 및 검토이다.
형상 감사는 변경이 계획서의 절차대로 진행되었는지, 변경 결과가 요구사항에 맞는지 검증·확인하는 활동이다.
형상 통제: 변경 요청을 검토·승인하고 기준선에 반영하도록 통제하는 활동이다.
형상 식별: 관리 대상 형상 항목을 정하고 식별자를 부여하는 활동이다.
형상 상태 보고: 형상 항목의 변경 이력과 현재 상태를 기록·보고하는 활동이다.

옳지 않은 설명은 최종 종료 단계에서만 오류를 탐지할 수 있다는 것이다.
프로토타입 모델은 시제품을 일찍 만들어 사용자 피드백을 받으므로 개발 초기부터 요구 오류를 발견할 수 있다. 막바지에야 결과를 확인하는 것은 폭포수 모델의 단점이다.
프로토타입을 보며 사용자가 새로운 요구사항을 발견할 수 있다는 설명은 장점으로 옳다.
사용자가 시제품을 완성품으로 오인할 수 있다는 설명은 대표적 단점으로 옳다.
반복 수정이 이어져 관리·통제가 어렵다는 설명도 단점으로 옳다.

SPICE 성숙도 수준에 속하지 않는 것은 정의(defined) 단계이다.
SPICE의 능력 수준은 불완전(incomplete), 수행(performed), 관리(managed), 확립(established), 예측(predictable), 최적화(optimizing)의 6단계다. '정의' 단계는 CMMI 단계적 표현의 명칭이다.
수행 단계: 프로세스 목적을 달성하는 수준으로 SPICE에 있다.
관리 단계: 프로세스를 계획·관리하는 수준으로 SPICE에 있다.
최적화 단계: 프로세스를 지속적으로 개선하는 최상위 수준으로 SPICE에 있다.

실행 결과는 Truck 다음 줄에 Camping car가 출력된다.
참조형이 Car여도 실제 객체가 Campingcar이므로 동적 바인딩에 따라 Campingcar의 type()이 호출된다. 그 안의 super.type()은 바로 위 부모인 Truck의 type()을 호출해 Truck을 출력하고, 이어서 Camping car를 출력한다.
Car만 출력: 참조 타입 기준으로 메소드가 선택된다고 착각한 결과다.
Camping car만 출력: super.type() 호출을 빠뜨린 결과다.
Car와 Truck 출력: Car의 type()은 하위 클래스에서 재정의되어 호출되지 않으며, Campingcar 자신의 출력도 빠졌다.

순환 복잡도가 4인 코드는 penalty 메소드이다.
순환 복잡도는 결정(조건) 수 + 1로 구할 수 있다. penalty에는 speed>200, speed<150, speed<=100의 if가 3개 있으므로 3 + 1 = 4이다.
max: if 하나뿐이라 복잡도는 2이다.
bonus: if와 else if 두 결정이라 복잡도는 3이다.
calculate: while과 if 두 결정이라 복잡도는 3이다.

적용된 디자인 패턴은 퍼사드(facade)이다.
Hello는 Korea·Japan·China를 직접 다루지 않고 Greeting의 say() 하나만 호출한다. 여러 하위 클래스를 감싸 단순한 통합 인터페이스를 제공하는 것이 퍼사드의 특징이다.
브릿지: 추상화와 구현을 분리해 각각 독립적으로 확장하게 하는 패턴으로, 추상-구현 계층 분리가 코드에 없다.
어댑터: 호환되지 않는 인터페이스를 변환해 맞춰 주는 패턴으로, 인터페이스 변환이 없다.
컴포지트: 객체를 트리 구조로 구성해 부분과 전체를 동일하게 다루는 패턴으로, 계층 구조가 없다.

코드의 결합도는 공통(common) 결합도이다.
main()과 getadd()가 매개변수 없이 전역 변수 a, b를 함께 읽고 쓰며 데이터를 주고받는다. 이처럼 공유 전역 데이터 영역을 참조하는 것이 공통 결합도다.
스탬프 결합도: 자료구조(레코드·객체) 전체를 매개변수로 넘기는 경우로, 이 코드에는 매개변수 전달이 없다.
제어 결합도: 플래그 같은 제어 정보를 넘겨 상대 모듈의 흐름을 바꾸는 경우로, 해당 사항이 없다.
내용 결합도: 다른 모듈의 내부 코드나 지역 데이터를 직접 참조·변경하는 경우로, 이 코드는 전역 변수만 공유한다.

제시된 세부 특성을 모두 포함하는 품질 특성은 기능성(functionality)이다.
ISO/IEC 9126에서 기능성의 부특성은 적합성·정확성·상호운용성·보안성·준수성이다.
신뢰성: 성숙성·결함 허용성·회복성 등을 부특성으로 가진다.
사용성: 이해성·학습성·운용성 등을 부특성으로 가진다.
안정성: ISO/IEC 9126의 주 품질 특성이 아니며, 유지보수성의 부특성 명칭으로 쓰인다.

옳지 않은 설명은 자원의 단위와 단가 정보를 작성한다는 것이다.
WBS는 프로젝트 범위를 작업 단위로 분해한 계층 구조일 뿐이며, 자원 단가와 비용은 WBS를 바탕으로 이후 원가 산정·예산 수립 단계에서 작성한다.
프로젝트를 구성 요소로 나누어 계층적으로 기술한 구조라는 설명은 옳다.
산출물 중심 또는 프로세스 중심으로 작성할 수 있다는 설명은 옳다.
전체 범위를 정의하고 계획·관리의 기초 자료로 쓴다는 설명은 옳다.

옳지 않은 설명은 측정 유형에 내부 연계파일이 있다고 한 것이다.
기능점수 측정 유형은 데이터 기능인 내부 논리파일(ILF)·외부 연계파일(EIF)과 트랜잭션 기능인 외부 입력(EI)·외부 출력(EO)·외부 조회(EQ)의 5가지다.
소프트웨어 기능을 데이터 기능과 트랜잭션 기능으로 구분한다는 설명은 옳다.
개발 전 사용자 관점에서 측정하며 개발 언어와 무관하다는 설명은 옳다.
개발·유지관리·재개발 비용 산정에 사용한다는 설명은 옳다.

프로젝트 최단 완료 기간은 가장 긴 경로인 임계 경로 A→C→G→F→J의 합인 30일이다.
각 작업의 가장 빠른 종료 시점(선행 작업 종료 최댓값 + 자기 기간)을 앞에서부터 구한다.
A 5, B 5+4=9, C 5+7=12, D 9+6=15, E max(9,12)+8=20, G 12+2=14
F max(9,12,14)+8=22, H max(15,20)+5=25, I max(20,25)+4=29, J max(22,14)+8=30
종료 작업 I(29일)와 J(30일) 중 늦은 쪽이 프로젝트 완료 시점이 되며, 임계 경로 기간 합은 5+7+2+8+8=30이다.
21일: A→B→E→I 경로의 합으로, 더 긴 경로를 무시한 값이다.
24일: A→B→D→H→I 경로의 합으로, 역시 임계 경로가 아니다.
28일: A→C→F→J 경로의 합으로, G를 거쳐 F로 가는 더 긴 경로(30일)를 놓친 값이다.

옳은 설명은 논리적 관점이 클래스·시퀀스 다이어그램으로 시스템 기능을 설명한다는 것이다.
4+1 View에서 논리 뷰는 최종 사용자에게 제공할 기능을 객체 구조와 상호작용으로 표현하며, +1인 유스케이스(시나리오) 뷰가 나머지 네 뷰를 묶는다.
개발 관점: 사용자 기능이 아니라 소프트웨어 모듈·패키지 구성을 다루며 컴포넌트·패키지 다이어그램을 쓴다.
물리적 관점: 개발 방식이 아니라 소프트웨어가 하드웨어 노드에 어떻게 배치되는지를 다루며 배치 다이어그램을 쓴다.
프로세스 관점: 하드웨어 환경이 아니라 실행 시 동시성·프로세스 간 상호작용을 다루며 활동·시퀀스 다이어그램을 쓴다.

코드에 제시된 설계 원칙은 캡슐화이다.
필드 name·dept를 private으로 숨기고 public getter·setter 메소드로만 접근하게 하여 정보 은닉을 구현했다.
다형성: 같은 메시지에 객체별로 다르게 동작하는 성질로, 오버라이딩·오버로딩이 코드에 없다.
상속: 상위 클래스의 속성·메소드를 물려받는 것으로, extends 관계가 없다.
추상화: 공통 특성을 뽑아 추상 클래스·인터페이스로 정의하는 것으로, 해당 구조가 없다.