[경찰간부후보생 소프트웨어공학] 23년 1회차 기출문제 정답·해설 페이지

제시된 요구에 가장 적합한 모델은 점증적 프로세스 모델이다.
초기에 전체 요구를 확정해 서브시스템으로 나누고, 릴리즈 계획에 따라 설계–구현/시험–설치/운영을 반복하며 단계적으로 릴리즈하고, 서브시스템 병행 개발과 표준 절차 준수를 요구하는 것은 점증적 모델의 특징이다.
Agile 모델은 요구를 초기에 모두 확정하지 않고 짧은 반복마다 변경을 수용하므로, 초반 전체 요구 확정과 엄격한 표준 절차 요구와 맞지 않는다.
폭포수 모델은 전체를 한 번에 개발해 마지막에 인도하므로, 작동하는 SW를 조기에 단계적으로 제공받으려는 요구와 맞지 않는다.
Spiral 모델은 반복마다 위험 분석을 중심으로 요구와 계획을 다시 세우는 모델로, 처음에 모든 요구와 릴리즈 시기를 확정하는 방식이 아니다.

적절하지 않은 설명은 MOM이 강한 결합의 동기 기술이라는 내용이다.
MOM은 메시지 큐를 매개로 송신측과 수신측을 분리하는 느슨한 결합의 비동기 통신 미들웨어로, 수신측이 즉시 응답하지 않아도 메시지가 전달된다.
CORBA는 OMG가 제정한 ORB 기반 분산 객체 표준으로 이기종 환경의 상호운용을 지원한다.
애플리케이션 서버는 N-tier 구조의 중간층에서 분산 통신·보안·트랜잭션 등을 제공하는 컴포넌트 기반 서버이다.
P2P 구조는 각 노드가 클라이언트이자 서버 역할을 하며 블록체인이 대표 사례이다.

적절하지 않은 설명은 배치 다이어그램을 컴포넌트 간 커넥션과 연결 구조를 나타내는 것으로 설명한 내용이다.
배치 다이어그램은 노드(하드웨어·실행 환경)와 그 위에 배치되는 산출물의 물리적 배치를 표현하며, 컴포넌트 간 연결 구조는 컴포넌트 다이어그램이나 복합 구조 다이어그램이 다룬다.
커뮤니케이션 다이어그램은 순차 다이어그램과 같은 상호작용을 객체 간 연결 관계 중심의 네트워크 형태로 표현한다.
인터랙션 오버뷰 다이어그램은 활동 다이어그램 형식 안에 상호작용을 배치해 메시지 교환과 제어 흐름을 함께 보여 준다.
패키지 다이어그램은 관련 요소를 패키지로 묶어 패키지 간 의존 관계를 관리하는 데 쓰인다.

프로젝트 소요기일은 가장 긴 경로인 임계 경로의 길이로, 18일이다.
마일스톤은 소요시간이 0이며, 선행 작업이 모두 끝나야 통과한다. 따라서 M2는 A(3일)·B(5일) 중 늦은 5일, M5는 C(6일)·D(10일) 중 늦은 10일에 도달한다.
임계 경로는 시작 → B → M2 → D → M5 → G → M7 → H → 완료이다.
$5+5+3+5=18$
16일: 임계 경로보다 짧은 값이다. A를 거쳐 M2에 도달하는 3일을 기준으로 잡으면 B가 끝나기 전에 D를 시작하는 셈이 되어 기간이 줄어든다.
8일: 가장 짧은 경로(F → M4 → J → K, 3+3+2)의 길이로, 최장 경로가 아니다.
20일: 네트워크의 어떤 경로를 합해도 나오지 않는 값이다. I 경로는 15일(B → M3 → E → M6 → I), K 경로는 8일에 그친다.

적절하지 않은 내용은 CPI가 1.2라는 것이다.
PV는 1억의 60%인 6천만 원, EV는 1억의 52%인 5천2백만 원, AC는 5천만 원이다.
$\mathrm{CPI}=\dfrac{\mathrm{EV}}{\mathrm{AC}}=\dfrac{52{,}000{,}000}{50{,}000{,}000}=1.04$
따라서 CPI는 1.04로, 비용 효율이 계획보다 약간 나은 수준이다.
SV는 $\mathrm{EV}-\mathrm{PV}=52{,}000{,}000-60{,}000{,}000=-8{,}000{,}000$원으로 맞다.
CV는 $\mathrm{EV}-\mathrm{AC}=2{,}000{,}000$원으로 맞다.
SPI는 $\dfrac{52}{60}\approx 0.867$로, 소수 셋째 자리를 버리면 0.86이 되어 맞다.

GoF 디자인 패턴에 속하지 않는 것은 단순 팩토리(Simple Factory)이다.
단순 팩토리는 객체 생성 코드를 한 클래스에 모아 두는 관용적 기법으로 GoF의 23가지 패턴 목록에는 없다. GoF 생성 패턴은 추상 팩토리·빌더·팩토리 메서드·프로토타입·싱글턴이다.
추상 팩토리는 관련 객체군을 구체 클래스 지정 없이 생성하는 GoF 생성 패턴이다.
팩토리 메서드는 생성할 객체의 클래스 결정을 하위 클래스에 맡기는 GoF 생성 패턴이다.
템플릿 메서드는 알고리즘 골격을 상위 클래스에 두고 일부 단계를 하위 클래스가 정의하는 GoF 행위 패턴이다.

요구분석 단계의 올바른 순서는 도메인 분석 → 요구 추출 → 분석과 명세화 → 검토이다.
먼저 업무 영역(도메인)을 이해해야 이해관계자로부터 요구를 끌어낼 수 있고, 추출한 요구를 분석·정리해 명세서로 작성한 뒤 마지막에 검토로 명세의 정확성과 완전성을 확인한다.
요구 추출 → 도메인 분석 → 명세화 순서는 업무 이해 없이 요구부터 수집하게 되어 맞지 않다.
요구 추출 → 분석과 명세화 → 도메인 분석 순서는 명세가 끝난 뒤에야 도메인을 분석하게 되어 맞지 않다.
도메인 분석 → 명세화 → 요구 추출 순서는 수집하지도 않은 요구를 먼저 문서화하게 되어 맞지 않다.

S/W 관리 측면에 속하지 않는 것은 SW 유지보수이다.
SWEBOK의 지식 영역을 개발 측면과 관리 측면으로 나누면, 요구사항·설계·구현·테스트·유지보수는 제품을 만드는 개발 측면에, 형상관리·공학 관리·프로세스·도구와 방법론·품질은 관리 측면에 속한다.
SW 형상관리는 산출물의 변경을 통제하는 관리 측면 영역이다.
SW 프로세스는 개발 프로세스의 정의·평가·개선을 다루는 관리 측면 영역이다.
SW 도구, 방법론은 개발을 지원하는 도구와 방법을 다루는 관리 측면 영역이다.

형상변경 제어 활동이 아닌 것은 형상 항목에 대한 검토와 확인이다.
검토(verification)와 확인(validation)은 형상 항목이 요구와 기준선에 맞게 변경되었는지 점검하는 형상 감사 활동이다. 변경 제어는 변경 요청을 받아 이유와 영향을 분석하고 승인·계획하는 과정이다.
형상 항목 변경 계획 수립은 승인된 변경을 어떻게 반영할지 정하는 변경 제어 활동이다.
형상 항목 변경의 이유 파악은 변경 요청을 평가하는 변경 제어 활동이다.
형상 항목 변경 영향도 분석은 변경 승인 여부를 판단하기 위한 변경 제어 활동이다.

적절하지 않은 설명은 메시지 화살표 위에 송신 객체의 함수명을 쓴다는 내용이다.
메시지는 수신 객체에게 작업을 요청하는 것이므로 화살표 위에는 수신 객체가 제공하는 함수(오퍼레이션)명을 적는다.
객체 생명선은 객체 아래로 내려가는 수직 점선이며 위에서 아래로 시간이 흐른다.
객체명은 객체명:클래스명 형태로 쓰며, 클래스명만 써서 익명 객체로 표기할 수도 있다.
응답을 기다리는 호출은 동기 메시지, 기다리지 않는 호출은 비동기 메시지로 설계한다.

sender와 receiver 사이는 자료 결합도, receiver는 논리적 응집도로 보는 것이 적절하다.
sender는 receiver에 정수 두 개만 매개변수로 넘기고 결과 값만 돌려받으며 제어 플래그를 넘기지 않으므로 가장 느슨한 자료 결합도이다.
receiver는 입력값 비교 결과에 따라 a*3과 b*2라는 서로 다른 처리 중 하나를 골라 수행하므로, 유사한 성격의 처리를 한 모듈에 모아 조건으로 선택하는 논리적 응집도로 판단한다.
제어 결합도와 기능적 응집도의 조합은 플래그 전달이 없고 receiver가 조건에 따라 다른 계산을 고르므로 둘 다 맞지 않다.
자료 결합도와 기능적 응집도의 조합은 결합도는 맞지만 receiver가 단일 기능만 수행한다고 보기 어려워 응집도가 맞지 않다.
제어 결합도와 논리적 응집도의 조합은 응집도는 맞지만 순수 데이터만 넘기므로 결합도가 맞지 않다.

설명된 설계가 만족하는 원칙은 개방 폐쇄의 원칙(OCP)이다.
새 정렬 알고리즘을 상속과 다형성으로 추가하므로 기능 확장에는 열려 있고, client 코드는 수정하지 않아도 되므로 변경에는 닫혀 있다.
단일 책임의 원칙은 클래스가 하나의 변경 이유(책임)만 가져야 한다는 원칙으로, 확장 시 기존 코드 보호와는 초점이 다르다.
인터페이스 분리의 원칙은 클라이언트가 쓰지 않는 메서드에 의존하지 않도록 인터페이스를 잘게 나누라는 원칙이다.
리스코프 대체의 원칙은 하위 타입이 상위 타입을 대체해도 프로그램이 올바르게 동작해야 한다는 상속 정합성에 관한 원칙이다.

팬아웃 과다 문제를 해소하기에 가장 적절한 패턴은 Facade 패턴이다.
Facade는 여러 하위 모듈 앞에 단일 통합 인터페이스를 두어, 많은 모듈을 직접 호출하던 것을 하나의 창구 호출로 바꾸므로 팬아웃과 결합도가 줄어든다.
Adapter 패턴은 호환되지 않는 인터페이스를 변환해 맞춰 주는 패턴으로, 호출 대상 수를 줄이는 목적이 아니다.
Bridge 패턴은 추상과 구현을 분리해 각각 독립적으로 확장하게 하는 패턴이다.
Composite 패턴은 부분과 전체를 트리 구조로 구성해 개별 객체와 복합 객체를 동일하게 다루는 패턴이다.

럼바우 OMT의 올바른 대응은 객체 모델–클래스, 동적 모델–상태, 기능 모델–데이터 흐름 다이어그램이다.
객체 모델은 객체와 관계를 클래스(객체) 다이어그램으로, 동적 모델은 시간에 따른 상태 변화를 상태 다이어그램으로, 기능 모델은 입력이 출력으로 변환되는 과정을 자료 흐름도(DFD)로 표현한다.
객체 모델–상태, 동적 모델–데이터 흐름, 기능 모델–클래스 조합은 세 모델이 모두 어긋난다.
객체 모델–데이터 흐름, 동적 모델–클래스, 기능 모델–상태 조합도 세 모델이 모두 어긋난다.
객체 모델–상태, 동적 모델–클래스 조합은 기능 모델만 맞고 나머지 둘이 뒤바뀌었다.

객체지향 설계 메트릭이 아닌 것은 싸이클로매틱 복잡도이다.
싸이클로매틱 복잡도는 McCabe가 제안한 제어 흐름 그래프 기반의 전통적(구조적) 복잡도 척도로, 객체지향 고유 개념과 무관하게 모든 프로그램에 적용된다.
클래스당 가중 메서드(WMC)는 클래스 메서드들의 복잡도 합을 재는 CK 메트릭이다.
메서드 응집 결핍(LCOM)은 클래스 내 메서드들이 속성을 공유하지 않는 정도를 재는 CK 메트릭이다.
상속 트리의 깊이(DIT)는 상속 계층에서 루트로부터 클래스까지의 깊이를 재는 CK 메트릭이다.

이 다이어그램이 위반한 원칙은 리스코프 대체의 원칙이다.
상위 클래스 고용인은 지급명세서()를 정의하고, 하위 클래스 네 개가 이를 상속한다. 그런데 자원봉사자는 급여를 받지 않으므로 지급명세서()를 의미 있게 수행할 수 없다.
하위 타입은 상위 타입을 대신해도 프로그램이 올바르게 동작해야 한다. 고용인 자리에 자원봉사자를 넣으면 이 약속이 깨진다.
단일 책임의 원칙: 한 클래스가 여러 변경 이유를 갖는 문제로, 이 그림의 핵심 결함은 상속 관계의 대체 가능성이다.
개방 폐쇄의 원칙: 기존 코드를 수정하지 않고 확장할 수 있어야 한다는 원칙으로, 하위 클래스를 추가하는 구조 자체는 이를 따른다.
의존성 역전의 원칙: 상위 모듈이 구체 클래스가 아닌 추상에 의존해야 한다는 원칙으로, 이 그림의 문제와 관련이 없다.

적절하지 않은 설명은 조건 커버리지가 50%라는 내용이다.
(-5, -2)는 $x \ge -3$이 거짓, $y \lt 5$가 참이고, (1, 7)은 $x \ge -3$이 참, $y \lt 5$가 거짓이다. 두 조건이 각각 참·거짓을 모두 가졌으므로 조건 커버리지는 100%이다.
반면 두 데이터 모두 전체 결정은 거짓이 되어 else 쪽 문장만 실행된다.
문장 커버리지는 if 문과 else 쪽 대입문은 실행되고 x=x+y는 실행되지 않아 3개 중 2개, 약 66%로 맞다.
결정 커버리지는 결정이 거짓 쪽만 나와 2개 결과 중 1개, 50%로 맞다.
조건-결정 커버리지는 조건과 결정을 함께 충족해야 하는데 결정이 절반만 충족되어 50%로 평가된다.

리팩토링의 이유로 적절하지 않은 것은 소프트웨어 인증 획득이다.
리팩토링은 외부 동작을 바꾸지 않고 내부 구조를 개선하는 활동으로, 목적은 설계 개선·이해 용이성·개발 속도 향상 같은 코드 품질에 있으며 인증 취득과는 관계가 없다.
설계 개선은 중복과 구조적 결함을 제거해 설계가 부패하는 것을 막는 대표적 목적이다.
이해를 쉽게 하는 것은 코드 가독성을 높여 다른 개발자가 읽기 쉽게 하려는 목적이다.
추가 기능 구현 속도 향상은 좋은 구조가 변경과 확장을 빠르게 해 주기 때문에 생기는 효과이다.

시스템의 가용성은 약 96%이다.
$A=\dfrac{\mathrm{MTBF}}{\mathrm{MTBF}+\mathrm{MTTR}}$
$A=\dfrac{3000}{3000+120}=\dfrac{3000}{3120}\approx 0.9615$
백분율로 약 96.15%이고, 소수점 이하를 반올림하면 96%가 된다.

적절하지 않은 설명은 CMMi와 SPICE의 등급 도출 방식을 서로 바꾸어 설명한 내용이다.
단계적 표현의 CMMi는 프로세스 영역들을 묶어 조직 전체에 하나의 성숙도 레벨을 부여하고, SPICE는 프로세스별로 능력 수준을 각각 평가한다.
CMMi는 1~5의 5단계, SPICE는 0~5의 6단계로 구분하므로 맞다.
CMMi는 프로세스 개선 목적이 강하고 SPICE는 자체 역량 평가나 계약 시 공급자 평가에 많이 쓰이므로 맞다.
프로세스가 최적화되고 지속적 개선이 이루어지는 수준은 두 모델 모두 5등급(최적화 단계)에 해당하므로 맞다.

설명하는 개념은 캡슐화이다.
데이터와 이를 조작하는 메서드를 하나로 묶고, 외부에는 기능과 사용법만 공개하며 내부 데이터는 메서드를 통해서만 바꾸게 하는 것이 캡슐화이며, 이를 통해 정보은닉이 실현된다.
모듈화는 시스템을 기능 단위의 모듈로 분할하는 설계 원리이다.
상속성은 상위 클래스의 속성과 메서드를 하위 클래스가 물려받는 개념이다.
다형성은 같은 메시지에 대해 객체마다 서로 다른 방식으로 응답하는 개념이다.

적절하지 않은 설명은 재공학에서 정공학과 역공학의 역할을 서로 바꾸어 설명한 내용이다.
기존 시스템에서 추상화된 설계 정보를 추출하는 것이 역공학이고, 새로운 요구사항에 맞춰 다시 구현하는 것이 정공학이다.
재공학은 기존 시스템을 개선하는 활동으로, 계속 유지보수할지 새로 개발할지 선택하는 시점에서 적용된다.
역공학은 시스템을 변경하지 않고 분석해 설계를 이해하는 데 중점을 둔다.
리스트럭처링은 비구조적 코드를 구조적 코드로 바꾸는 것으로, 변경 부분·빈도·의존도를 고려해 수행한다.

Level 3은 요구사항 개발·통합을 위한 조직의 환경·제품 통합, Level 5는 근본 원인 분석과 해결책으로 짝지은 것이 적절하다.
CMMi에서 요구사항 관리·프로세스 및 제품 품질 보증·공급업체 계약관리는 Level 2(관리), 정량적 프로젝트 관리는 Level 4(정량적 관리), 근본 원인 분석과 해결책은 Level 5(최적화)의 프로세스 영역이다.
통합을 위한 조직의 환경·요구사항 관리·제품 통합과 프로세스 및 제품 품질 보증의 조합은 Level 3 묶음에 Level 2 영역이 섞였고 Level 5 항목도 Level 2 영역이다.
공급업체 계약관리·정량적 프로젝트 관리·통합을 위한 조직의 환경과 프로세스 및 제품 품질 보증의 조합은 Level 2·4 영역이 섞였고 Level 5 항목도 맞지 않다.
프로세스 및 제품 품질 보증·공급업체 계약관리·요구사항 관리와 근본 원인 분석의 조합은 Level 5는 맞지만 Level 3 묶음이 모두 Level 2 영역이다.

설명하는 결합은 스탬프 결합이다.
스탬프 결합은 모듈 간에 레코드·배열 같은 자료구조 전체를 넘기는 결합으로, 일부 데이터만 필요해도 구조 전체가 전달되어 구조가 바뀌면 그 필드를 쓰지 않는 모듈까지 영향을 받는다.
데이터 결합은 필요한 단순 데이터 값만 매개변수로 주고받는 가장 느슨한 결합이다.
공통 결합은 여러 모듈이 전역 변수 같은 공통 데이터 영역을 함께 참조하는 결합이다.
내용 결합은 한 모듈이 다른 모듈의 내부 데이터나 코드를 직접 참조·변경하는 가장 강한 결합이다.

해당 코드의 오류는 메모리 누수이다.
n이 1이면 n > 0 조건으로 malloc이 먼저 실행되어 메모리가 할당되지만 곧바로 NULL을 반환하므로, 할당된 주소를 잃어 해제할 방법이 없는 메모리가 남는다.
NULL의 사용 오류는 NULL 포인터를 역참조하는 경우를 말하는데, 이 코드는 NULL을 반환할 뿐 역참조하지 않는다.
버퍼 오버플로는 할당 크기를 넘어 쓰는 경우인데, 이 코드에는 버퍼에 쓰는 동작이 없다.
중복된 프리는 같은 메모리를 두 번 해제하는 오류인데, 이 코드에는 free 호출 자체가 없다.

기능 요구사항이 아닌 것은 날짜 표기를 YYYY-MM-DD 형식으로 제공하라는 내용이다.
날짜 표기 형식은 시스템이 무엇을 하는지가 아니라 따라야 할 표준·형식에 관한 제약(비기능 요구사항)이다.
고객이 예약 관련 사항을 입력·수정하는 것은 시스템이 제공해야 할 기능이다.
호텔 직원이 예약정보를 등록·조회·수정하는 것도 시스템이 제공해야 할 기능이다.
사용자 역할별 정보 범위를 명시하는 것은 역할에 따라 다룰 수 있는 정보를 정하는 기능 요구로 본다.

적절한 설명은 운영 및 모니터링 단계에서 사용자 경험과 반응을 추적하고 척도 달성 여부를 확인한다는 내용이다.
DevOps는 계획–코드–빌드–테스트–배포–운영–모니터링이 순환하며, 운영 중 수집한 피드백이 다음 계획으로 이어진다.
비즈니스 가치와 요구사항 정의는 배포가 아니라 계획 단계의 활동이다.
요구사항을 기반으로 소스 코드를 개발하고 단위테스트하는 것은 테스트가 아니라 코드(개발) 단계의 활동이다.
배포된 애플리케이션의 설치 문제 복구와 인프라 구축은 빌드가 아니라 배포·운영 단계의 활동이다.

이 그래프의 순환 복잡도는 5이다.
순환 복잡도는 간선 수 − 노드 수 + 2로 구한다. 노드는 0부터 9까지 10개, 간선은 13개이다.
$V(G)=E-N+2=13-10+2=5$
분기 노드로 검산해도 같다. 노드 1은 4갈래(분기 3), 노드 2는 2갈래(분기 1)이므로 $3+1+1=5$이다.
3: 노드 1의 갈래를 분기 하나로만 세는 등 분기 수를 적게 센 값이다.
4: 노드 2의 분기를 빠뜨린 값이다.
6: 간선이나 분기를 하나 더 센 값이다.

리팩토링이 필요한 징후를 가리키는 용어는 코드의 나쁜 냄새(code smell)이다.
중복 코드, 긴 메서드, 거대한 클래스처럼 당장 오류는 아니지만 구조 개선이 필요함을 알려 주는 징후를 나쁜 냄새라 부른다.
두 개의 모자는 기능 추가와 리팩토링을 동시에 하지 말고 번갈아 하라는 작업 방식의 비유이다.
F.I.R.S.T는 단위 테스트가 갖춰야 할 성질(빠름·독립·반복 가능·자가 검증·적시)을 뜻한다.
TDD는 테스트를 먼저 작성하고 이를 통과하는 코드를 구현하는 개발 방식이다.

적절한 표현은 학생정보=ID+성명+(성별)+[생년월일|나이]이다.
자료 사전에서 ( )는 생략 가능, [ | ]는 여러 항목 중 하나 선택, { }는 반복을 뜻하므로 성별은 ( ), 생년월일과 나이는 [ | ]로 표현한다.
성별을 { }로 표현하면 생략이 아니라 반복이 되어 맞지 않다.
생년월일|나이를 { }로 묶으면 택일이 아니라 반복이 되어 맞지 않다.
성별과 생년월일|나이를 모두 { }로 표현하면 두 부분 모두 반복이 되어 맞지 않다.

데이터 추상화에 대한 설명이 아닌 것은 함수 내부 상세 없이 호출 방법과 수행 내용에 집중한다는 기능(절차) 추상화에 관한 설명이다.
데이터 추상화는 데이터 구조와 그 데이터에 대한 연산을 함께 정의하고 내부 표현을 감추는 것으로, 추상 자료형과 객체의 기초가 된다.
데이터와 조작을 함께 정의하는 것은 데이터 추상화의 핵심이다.
세부 표현을 감춰 시스템의 복잡성을 줄이는 것은 데이터 추상화의 효과이다.
서비스를 제공하는 객체의 집합으로 시스템을 보는 것은 데이터 추상화에 기반한 객체지향 관점이다.

화이트 박스 테스트 기법이 아닌 것은 도메인 테스트이다.
도메인 테스트는 입력 영역을 구간으로 나누고 그 경계를 점검하는 블랙박스 계열 기법으로, 내부 코드 구조가 아니라 명세된 입력 범위를 기준으로 한다.
분기 커버리지는 코드의 모든 분기가 참·거짓을 한 번 이상 수행하도록 하는 화이트박스 기법이다.
기본 경로 테스트는 순환 복잡도만큼의 독립 경로를 수행하는 화이트박스 기법이다.
MC/DC는 각 조건이 결정 결과에 독립적으로 영향을 주는지 확인하는 화이트박스 커버리지 기법이다.

결함이 오작동으로 이어지기 위한 조건이 아닌 것은 분할 조건이다.
결함이 실패로 드러나려면 결함 위치가 실행되고(도달), 프로그램 상태가 잘못 바뀌고(감염), 그 오류가 출력까지 전달되어야(전파) 하며, 이를 RIP 모델이라 한다.
도달성 조건은 결함이 있는 문장이 실제로 실행되어야 한다는 조건이다.
감염 조건은 결함 실행으로 프로그램의 내부 상태가 잘못되어야 한다는 조건이다.
오차 전파 조건은 잘못된 상태가 외부에서 관찰 가능한 출력까지 전달되어야 한다는 조건이다.

적절한 순서는 코딩 표준 작성 → 메서드 코딩 → 인스펙션 → 클래스 단위 테스트 → 운영 시스템 통합이다.
구현 전에 코딩 표준을 정하고, 설계를 반영해 코딩한 뒤 정적 검토인 인스펙션으로 결함을 걸러내고, 클래스 테스트를 거쳐 마지막에 릴리즈·통합한다.
테스트–통합–코딩 표준 작성–인스펙션–코딩 순서는 구현하기도 전에 테스트와 통합을 하는 셈이 되어 맞지 않다.
코딩–인스펙션–코딩 표준 작성–테스트–통합 순서는 코딩 표준을 코딩 이후에 작성해 맞지 않다.
코딩–인스펙션–코딩 표준 작성–통합–테스트 순서는 코딩 표준이 늦고 클래스 테스트 전에 운영 시스템에 통합해 맞지 않다.

팬인과 팬아웃의 차이가 1인 모듈은 C, D, G, H의 4개이다.
팬인은 해당 모듈을 호출하는 상위 모듈 수, 팬아웃은 해당 모듈이 호출하는 하위 모듈 수이다. 화살표를 따라 각 모듈을 세면 다음과 같다.
모듈
팬인
팬아웃
차이
A
0
4
4
B
1
1
0
C
1
2
1
D
1
2
1
E
1
1
0
F
2
2
0
G
2
1
1
H
2
1
1
I
2
0
2
J
3
1
2
2개: C, D처럼 팬아웃이 팬인보다 많은 모듈만 세고, 팬인이 더 많은 G, H를 빠뜨린 값이다.
3개: 차이가 1인 C, D, G, H 중 하나를 빠뜨린 값이다.
5개: J → I 호출을 놓치면 I의 팬인이 1로 줄어 차이 1이 되므로 I까지 함께 세게 된다.

설명하는 패턴은 Factory method 패턴이다.
객체 생성용 인터페이스는 상위 클래스가 정의하고, 어떤 클래스의 인스턴스를 만들지는 하위 클래스가 결정하도록 생성 책임을 위임하는 생성 패턴이다.
Adapter 패턴은 호환되지 않는 인터페이스를 변환해 함께 동작하게 하는 구조 패턴이다.
Facade 패턴은 복잡한 하위 시스템에 단순한 통합 인터페이스를 제공하는 구조 패턴이다.
Decorator 패턴은 객체에 기능을 동적으로 덧붙이는 구조 패턴이다.

가는 회귀 테스트, 나는 연쇄식(Threads) 통합 테스트이다.
회귀 테스트는 변경된 부분과 그 영향 범위를 다시 시험해 변경이 새 오류를 만들지 않았음을 확인하고, 연쇄식 통합은 핵심 기능을 수행하는 최소 모듈 집합을 먼저 구현·통합한 뒤 보조 모듈을 차례로 덧붙인다.
회귀 테스트와 스모크 테스트의 조합은 스모크 테스트가 빌드 직후 기본 동작만 빠르게 확인하는 테스트라서 나의 설명과 맞지 않다.
백투백 테스트와 스모크 테스트의 조합은 백투백이 여러 버전에 같은 입력을 주고 결과를 비교하는 테스트라서 가와 맞지 않고, 나도 맞지 않다.
백투백 테스트와 연쇄식 통합 테스트의 조합은 나는 맞지만 가의 변경 영향 확인 활동이 백투백 테스트가 아니라서 맞지 않다.