26년 1회차

V 모델은 요구사항이 초기에 명확히 확정된다는 전제에서 개발 단계와 테스트 단계를 대응시키는 순차형 모델이라 요구가 불명확한 프로젝트에는 맞지 않다.

요구가 모호할 때는 고객 피드백을 반복적으로 받아 요구를 구체화하는 반복·점진형 모델이 적합하다.

• 애자일 모델은 짧은 반복 주기마다 고객 피드백을 반영해 변화하는 요구에 대응한다.
• 프로토타이핑 모델은 견본을 먼저 만들어 고객이 직접 확인하게 하여 요구를 구체화한다.
• 나선형 모델은 반복마다 위험 분석과 고객 평가를 거쳐 불확실한 요구를 점차 확정한다.

작업 간 의존 관계와 임계경로를 파악하는 것은 WBS가 아니라 이를 바탕으로 작성하는 네트워크 일정표(CPM·PERT)의 역할이다.

WBS는 프로젝트 범위를 작업 단위로 계층 분할한 구조로, 작업 순서나 일정 관계는 담지 않는다.

• 목표 달성에 필요한 작업을 계층적으로 분할한다는 설명은 WBS의 정의이다.
• 전체 목표와 세부 목표를 트리나 표 형태로 표현한다는 설명은 WBS의 표현 방식이다.
• 자원 예측과 일정 수립의 기초 자료로 쓰인다는 설명은 WBS의 활용 목적이다.

표의 업무를 기능 유형별로 분류해 평균 가중치를 곱하면 총 기능점수는 46.7이다.

직접 저장·관리하는 회원 정보는 ILF 2개, 외부 결제시스템에서 받는 계좌 데이터는 EIF 1개, 가입·수정·탈퇴는 데이터를 변경하는 EI 3개, 단순 조회는 EQ 1개, 집계 결과를 만드는 통계 보고서는 EO 2개이다.

$\mathrm{ILF}: 2 \times 7.5 = 15$
$\mathrm{EIF}: 1 \times 5.4 = 5.4$
$\mathrm{EI}: 3 \times 4.0 = 12$
$\mathrm{EQ}: 1 \times 3.9 = 3.9$
$\mathrm{EO}: 2 \times 5.2 = 10.4$

$15 + 5.4 + 12 + 3.9 + 10.4 = 46.7$

매개변수 value 값에 따라 호출된 모듈이 버퍼 읽기와 쓰기 중 무엇을 할지 결정되므로 제어 결합이다.

제어 결합은 한 모듈이 제어 플래그를 넘겨 다른 모듈의 내부 처리 흐름을 지시하는 결합이다.

• 외부 결합은 외부에서 정의된 데이터 형식이나 장치 인터페이스를 여러 모듈이 공유할 때 생긴다.
• 데이터 결합은 처리에 필요한 단순 데이터만 주고받을 뿐 상대 모듈의 동작 흐름을 바꾸지 않는다.
• 스탬프 결합은 구조체·레코드 같은 자료구조 전체를 매개변수로 넘길 때 생긴다.

모듈 내부 요소가 하나의 기능에 꼭 필요한 것들로만 구성된 기능적 응집이 가장 강한 응집이다.

응집도는 기능적 > 순차적 > 교환적 > 절차적 > 시간적 > 논리적 > 우연적 순으로 약해진다.

• 이전 문장의 결과가 다음 문장의 입력이 되는 관계는 순차적 응집으로 기능적 응집보다 약하다.
• 실행 순서에 따라 요소를 묶은 것은 절차적 응집이다.
• 외부 출력 처리처럼 비슷한 성격의 처리 루틴을 묶은 것은 논리적 응집으로 강도가 낮다.

본사 클래스가 지사 구현 클래스에 직접 의존하던 구조를 인터페이스(추상화)에 의존하도록 바꾼 것이므로 의존 관계 역전의 원리이다.

상위 모듈과 하위 모듈이 모두 추상화에 의존하게 하면 하위 구현이 바뀌어도 상위 모듈은 영향을 덜 받는다.

• 개방 폐쇄의 원리는 기존 코드를 수정하지 않고 확장할 수 있게 하라는 원칙으로 의존 방향 전환이 핵심이 아니다.
• 인터페이스 분리의 원리는 클라이언트가 쓰지 않는 메소드에 의존하지 않도록 큰 인터페이스를 쪼개라는 원칙이다.
• 리스코프 교체의 원리는 하위 타입이 상위 타입을 대체해도 올바르게 동작해야 한다는 원칙이다.

사용자 인터페이스와 비즈니스 로직을 분리해 뷰를 모델과 독립적으로 변경할 수 있게 하는 구조는 MVC 스타일이다.

MVC는 모델·뷰·컨트롤러로 역할을 나눠 유지보수성과 확장성을 높이며 GUI 애플리케이션에 널리 쓰인다.

• 파이프 필터는 데이터가 필터를 차례로 통과하며 변환되는 스트림 처리 구조이다.
• P2P는 각 노드가 클라이언트와 서버 역할을 함께 수행하는 분산 구조이다.
• 레파지토리 구조는 공유 데이터 저장소를 중심으로 컴포넌트가 데이터를 주고받는 구조이다.

서브시스템의 여러 인터페이스 앞에 하나의 통일된 인터페이스를 두어 클라이언트와의 결합도를 낮추는 패턴은 Facade이다.

클라이언트는 퍼사드 객체만 다루므로 다룰 객체 수가 줄고 서브시스템 내부 구성이 감춰진다.

• Bridge는 추상화와 구현을 분리해 둘을 독립적으로 확장할 수 있게 하는 패턴이다.
• Adapter는 호환되지 않는 기존 인터페이스를 클라이언트가 기대하는 인터페이스로 변환한다.
• Proxy는 대리 객체를 두어 실제 객체에 대한 접근을 제어하거나 지연시킨다.

페이지의 영역 구분과 UI 요소 배치를 화면 단위 뼈대로 스케치하는 것은 와이어프레임이다.

와이어프레임은 색상·디자인보다 구조와 기능 배치에 집중한 저충실도 설계 산출물이다.

• 프로토타입은 실제처럼 동작을 시연·검증할 수 있게 만든 견본이다.
• 스토리보드는 화면 설계에 기능 설명·흐름·데이터 정보 등을 함께 정리한 상세 설계 문서이다.
• 여정 지도는 사용자가 서비스를 이용하며 겪는 단계별 경험과 감정을 시각화한 것이다.

통계적 방법으로 변수 조합을 골라 테스트 케이스 수를 줄이면서도 조합을 고르게 포함하는 기법은 직교 배열 테스트이다.

직교 배열은 실험계획법의 균형 잡힌 배열표를 이용해 각 값의 조합이 균등하게 나타나도록 케이스를 선정한다.

• 페어와이즈는 모든 두 변수 값의 쌍이 최소 한 번씩 나오도록 조합하는 기법이다.
• 원인-결과 그래프는 입력 조건과 출력 결과의 논리 관계를 그래프로 분석해 케이스를 도출한다.
• n-way는 임의의 n개 변수 값 조합이 모두 한 번 이상 나오도록 페어와이즈를 일반화한 조합 테스트 방식이다.

테스트 오라클은 테스트 결과가 올바른지 판단하기 위해 기대값을 제공하는 기준·메커니즘이며, 테스트 후 삭제되는 별도 프로그램이 아니다.

테스트가 끝난 뒤 제거되는 임시 프로그램은 통합 테스트에서 쓰는 드라이버와 스텁이다.

• 연쇄식 통합에서 연쇄는 특정 기능을 수행하는 모듈의 최소 단위를 말한다.
• 드라이버는 하위 모듈을 시험할 때 그 모듈을 호출하는 상위 역할의 간이 프로그램이다.
• 스텁은 시험 대상 모듈이 호출하는 하위 모듈의 기능을 대신하는 간이 프로그램이다.

(가)는 E(Exclusive), (나)와 (다)는 모두 R(Requires)이므로 조합은 E R R이다.

남직원과 여직원은 동시에 참일 수 없는 원인이므로 둘을 잇는 (가)는 배타 제약이다. 원인 %에서 남직원·여직원으로 향하는 화살표 (나)·(다)는 '%가 성립하려면 해당 원인이 먼저 성립해야 한다'는 요구 제약이다.

• E M R: (나)는 원인 사이의 화살표이므로 결과 사이에 쓰는 M(Masks)이 아니라 R이다.
• I R M: (가)의 I(Inclusive)는 적어도 하나는 참이어야 한다는 제약인데, 직원이 아닌 경우('출입 불가')가 있으므로 맞지 않고, (다)도 M이 아니라 R이다.
• I M M: (가)는 배타 제약 E이고, (나)·(다)는 원인 간 요구 제약 R이므로 모두 맞지 않는다.

스크럼은 제품 백로그 작성 → 스프린트 계획 → 일일 스크럼 → 결과물 완성 → 스프린트 검토 순으로 진행된다.

요구사항에 우선순위를 매긴 제품 기능 목록에서 출발해, 스프린트 구현 목록과 시간을 추정한 뒤 매일 회의와 소멸 차트로 진행을 관리한다.

스프린트가 끝나면 실행 가능한 결과물을 완성하고, 검토 회의를 거쳐 차기 스프린트 계획으로 이어진다.

프로그램 (가)의 순환 복잡도는 5, 제어흐름 그래프 (나)의 순환 복잡도는 4이다.

(가)에는 판단문이 if, if, if-else, while 네 개 있으므로 판단 수에 1을 더해 5가 된다.

(나)는 노드 9개, 간선 11개이다.
$V(G)=E-N+2=11-9+2=4$
분기하는 노드가 3개이므로 3+1로 계산해도 같다.

• (가)와 (나)를 모두 4로 본 조합: (가)의 while 반복도 판단문이므로 (가)는 5이다.
• (가)와 (나)를 모두 5로 본 조합: (나)는 간선·노드 수로 계산하면 4이다.
• (가) 4, (나) 5인 조합: 두 값이 서로 뒤바뀌었다.

품질 속성 간 충돌과 상충점을 분석하는 방법은 ATAM, 투자 대비 효과를 경제적 측면에서 평가하는 방법은 CBAM이다.

ATAM은 품질 속성 간의 트레이드오프를 찾아 설계 타협점을 도출하며, CBAM은 ATAM 결과에 비용·편익 분석을 더해 수익이 최대인 아키텍처를 고른다.

• SAAM은 변경 용이성 등을 시나리오 중심으로 평가하는 초기 방법으로 품질 속성 간 상충 분석이나 경제성 평가를 핵심으로 하지 않는다.

(가)는 public, (나)는 private, (다)는 protected, (라)는 extends Member이다.

UML 가시성 표기에서 +는 public, -는 private, #는 protected이다. id와 login()은 +, pwd는 -, age는 #이고, Professor·Student에서 Member로 향하는 빈 삼각형 화살표는 클래스 상속(일반화)이므로 자바에서 extends로 표현한다.

• public protected private extends Member: pwd의 -와 age의 # 표기를 서로 바꿨다.
• public protected private implements Member: 가시성이 뒤바뀌었고, implements는 인터페이스 실현에 쓰므로 일반 클래스 Member의 상속에는 맞지 않다.
• public private protected implements Member: 가시성은 맞지만 Member는 일반 클래스이므로 implements가 아니라 extends로 상속한다.

ISO/IEC 25000(SQuaRE)에서 2504n 부문은 개발자·구매자·평가자 관점의 품질 평가 프로세스를 다룬다.

SQuaRE는 품질 관리(2500n), 품질 모델(2501n), 품질 측정(2502n), 품질 요구(2503n), 품질 평가(2504n) 부문으로 구성된다.

• SQuaRE 개요와 전체 계획·관리는 2500n 부문의 내용이다.
• 품질 모델과 사용 품질에 대한 안내는 2501n 부문의 내용이다.
• 내·외부 메트릭과 사용 중 품질 메트릭은 2502n 측정 부문의 내용이다.

동일한 인스턴스를 공유해 대량 객체의 메모리 사용량을 줄이는 구조 패턴은 플라이웨이트 패턴이다.

플라이웨이트는 공유 가능한 내부 상태를 하나의 객체로 두고 개별 상태만 외부에서 주입해 객체 수를 줄인다.

• 프록시 패턴은 대리 객체로 실제 객체에 대한 접근을 제어하는 구조 패턴이다.
• 프로토타입 패턴은 기존 객체를 복제해 새 객체를 만드는 생성 패턴이다.
• 컴포지트 패턴은 부분과 전체를 트리 구조로 구성해 동일하게 다루는 구조 패턴이다.

형상 관리 대상 항목을 선정하고 베이스라인 기준을 정하는 단계는 형상 식별이다.

형상 관리는 대체로 식별 → 통제 → 감사 → 상태 보고 순으로 진행되며, 식별 단계에서 관리 대상에 이름과 번호를 부여한다.

• 형상 통제는 베이스라인에 대한 변경 요청을 검토·승인해 반영하는 단계이다.
• 형상 감사는 베이스라인 변경이 요구대로 정확히 이루어졌는지 검증하는 단계이다.
• 형상 상태 보고는 변경 사항과 처리 상태를 기록해 관련자에게 알리는 단계이다.

기존 코드를 수정하지 않고 새 코드를 추가해 확장할 수 있게 하라는 원칙은 개방 폐쇄의 원리이다.

확장에는 열려 있고 변경에는 닫혀 있도록, 변하지 않는 부분을 추상 부모 클래스로 두고 변하는 부분을 자식 클래스로 확장한다.

• 단일 책임의 원리는 클래스가 하나의 책임만 가져야 한다는 원칙이다.
• 인터페이스 분리의 원리는 클라이언트가 쓰지 않는 메소드에 의존하지 않도록 인터페이스를 나누라는 원칙이다.
• 리스코프 교체의 원리는 하위 클래스가 상위 클래스를 대체해도 올바르게 동작해야 한다는 원칙이다.

핵심 아키텍처를 확정하고 주요 위험 요소를 찾아 줄이는 단계는 UP의 정련(elaboration) 단계이다.

정련 단계에서는 아키텍처 기준선(베이스라인)을 수립하고 중대한 위험을 제거해 이후 구축의 토대를 마련한다.

• 도입 단계는 프로젝트 범위와 사업 타당성을 정의하는 단계이다.
• 구축 단계는 확정된 아키텍처 위에서 나머지 기능을 구현해 제품을 완성하는 단계이다.
• 전이 단계는 완성된 제품을 사용자 환경에 배포하고 인도하는 단계이다.

가용성 90%를 얻으려면 MTTF가 900시간이어야 한다.

가용성 공식은 다음과 같다.
$A = \dfrac{\mathrm{MTTF}}{\mathrm{MTTF} + \mathrm{MTTR}}$

값을 대입한다.
$0.9 = \dfrac{\mathrm{MTTF}}{\mathrm{MTTF} + 100}$
$0.1 \times \mathrm{MTTF} = 90$
$\mathrm{MTTF} = 900\,\mathrm{h}$

현재 가용성은 400/500 = 80%이므로, MTTR을 유지한 채 MTTF를 늘려야 90%에 도달한다.

계정 정지와 전자 영수증 발송은 시스템이 수행해야 할 기능을 기술하므로 기능적 요구사항이다.

기능적 요구사항은 시스템이 무엇을 하는가, 비기능적 요구사항은 성능·가용성·제약 등 어떻게·어떤 조건에서 동작하는가를 다룬다.

• 연중무휴 24시간 운영은 가용성에 관한 비기능적 요구사항이다.
• 표준 SQL만 사용해야 한다는 것은 구현 방식에 대한 제약 사항으로 비기능적 요구사항이다.

type 값에 따라 성격이 비슷한 여러 처리를 한 함수에 몰아넣은 구조는 논리적 응집이며, 이는 조건문을 다형성으로 대체하는 리팩토링으로 개선한다.

공제 유형별로 클래스를 나누고 공통 메소드를 재정의하게 하면 switch 분기가 사라지고 유형 추가 시 기존 코드를 고치지 않아도 된다.

• 기능적 응집은 하나의 기능에 필요한 요소만 모인 경우로, 여러 공제 계산이 분기로 섞인 이 함수에 해당하지 않는다.
• 순차적 응집은 한 처리의 출력이 다음 처리의 입력이 되는 관계인데, 이 함수의 분기들은 서로 데이터를 주고받지 않는다.
• 우연적 응집은 아무 관련 없는 요소가 묶인 경우인데, 이 함수의 분기들은 모두 공제 계산이라는 같은 범주에 속한다.

컴포넌트는 내부 소스 코드를 수정하지 않고 공개된 인터페이스만으로 조립해 재사용하는 것이 원칙이다.

CBD는 검증된 컴포넌트를 블랙박스처럼 조합해 생산성과 품질을 높이는 개발 방식이다.

• 컴포넌트는 독립적으로 배포하고 교체할 수 있는 소프트웨어 단위이다.
• 컴포넌트는 명세된 인터페이스를 통해서만 기능을 제공하고 내부 구현을 감춘다.
• 검증된 컴포넌트를 조립하므로 개발 기간을 단축할 수 있다.

객체 간 관계를 링크로 표현하는 것은 순차 다이어그램이 아니라 커뮤니케이션 다이어그램의 특징이다.

순차 다이어그램은 생명선과 메시지를 시간 순서에 따라 배치해 상호작용을 나타내며, 객체 간 링크는 그리지 않는다.

• 활동 다이어그램은 업무 흐름에서 수행되는 활동과 처리 흐름을 나타낸다.
• 상태 다이어그램은 이벤트나 시간에 따라 바뀌는 객체의 상태 변화를 나타낸다.
• 컴포넌트 다이어그램은 구현 관점의 정적 모델로 실행 모듈 간 종속 관계를 나타낸다.

프로토타입 모델은 모형 선제작, 폭포수 모델은 순차 단계 진행, 스크럼은 짧은 주기의 반복 개발과 연결된다.

프로토타입 모델은 완성품 전에 사용자 요구를 반영한 견본을 만들어 요구를 확인한다.

• 폭포수 모델은 각 단계를 마친 뒤에야 다음 단계로 넘어가는 순차형 모델이므로 반복 개발과 연결되지 않는다.
• 스크럼은 스프린트라는 짧은 주기를 반복하며 점진적으로 제품을 만드는 애자일 방법이므로 순차 단계나 모형 선제작과 연결되지 않는다.

다이어그램에 적용되지 않은 개념은 오버로딩(overloading)이다.

오버로딩은 한 클래스 안에서 이름은 같고 매개변수가 다른 메서드를 여러 개 두는 것인데, 각 클래스에는 매개변수 없는 calArea() 하나만 있어 오버로딩이 나타나지 않는다.

• 상속(inheritance): Triangle·Rectangle·Circle이 일반화 화살표로 Shape를 상속하며 area를 물려받는다.
• 오버라이딩(overriding): 하위 클래스마다 상위 클래스의 calArea()를 같은 시그니처로 재정의한다.
• 다형성(polymorphism): Shape 타입으로 calArea()를 호출해도 실제 객체에 따라 도형별 면적 계산이 수행된다.

복잡도를 반영한 총 노력은 200MM이고 5명이 투입되므로 최소 소요 기간은 40개월이다.

기본 노력을 구한다.
$200000 \div 1200 \approx 166.7\,\mathrm{MM}$

복잡도 계수를 곱한다.
$166.7 \times 1.2 = 200\,\mathrm{MM}$

개발자 수로 나눈다.
$200 \div 5 = 40$

복잡도 계수는 노력을 늘리는 방향으로 적용되므로 곱해서 반영한다.

구조와 알고리즘의 구체적 명세는 설계 단계의 산출물이므로 요구분석명세서 검증 항목으로 적절하지 않다.

요구분석명세서는 시스템이 무엇을 해야 하는지를 기술하며, 완전성·명확성·일관성 등을 검증한다.

• 기능과 비기능 요구사항이 빠짐없이 작성되었는지 보는 것은 완전성 검증이다.
• 모호하지 않고 모두가 명확히 이해할 수 있는지 보는 것은 명확성 검증이다.
• 요구사항 간 모순·충돌이 없는지 보는 것은 일관성 검증이다.

G 작업의 소요 시간은 1이므로 최소 시간이 2라는 설명이 틀렸다.

G의 늦은 시작은 12이고 후속 작업 H의 늦은 시작은 13이므로 G의 늦은 종료는 13이다.
$13 - 12 = 1$

여유 시간(늦은 시작 − 빠른 시작)은 A 2, E 1, G 1이고 나머지 B·C·D·F·H는 0으로 임계 경로를 이룬다.

• A의 여유 시간 2가 가장 크므로 여유 시간이 가장 많은 작업은 A이다.
• D는 여유 시간이 0이어서 임계 경로에 포함된다.
• E는 여유 시간이 1이어서 임계 경로에 포함되지 않는다.

더하기·빼기·곱하기·나누기처럼 성격이 비슷한 연산을 한 클래스에 모아 둔 구조는 논리적 응집으로 본다.

논리적 응집은 같은 범주에 속하는 처리들을 묶어 두고 필요한 것을 골라 쓰는 형태로, 각 연산끼리는 데이터나 실행 순서로 연결되지 않는다.

• 기능적 응집은 모든 요소가 하나의 기능 수행에 협력하는 경우로, 서로 독립적인 네 연산이 나열된 이 클래스와 다르다.
• 절차적 응집은 요소들이 정해진 실행 순서에 따라 묶인 경우인데, 이 연산들은 순서와 무관하게 각각 호출된다.
• 우연적 응집은 서로 관련 없는 요소가 묶인 경우인데, 이 연산들은 모두 사칙연산이라는 공통 범주를 가진다.

배열·레코드·구조체 같은 자료구조를 매개변수로 넘기는 결합은 데이터 결합이 아니라 스탬프 결합이다.

데이터 결합은 필요한 단순 데이터 값만 매개변수로 주고받는 가장 느슨한 결합이다.

• 결합도는 모듈 간 상호 의존 정도를 평가하는 기준이다.
• 제어 결합은 제어 플래그를 넘겨 다른 모듈의 처리 흐름을 결정하는 결합이다.
• 공통 결합은 여러 모듈이 전역 변수 같은 공통 데이터 영역을 공유하는 결합이다.

클라이언트가 사용하지 않는 메소드에 의존하면 안 된다는 것은 인터페이스 분리의 원리로, 리스코프 교체의 원리에 대한 설명이 아니다.

리스코프 교체의 원리는 하위 클래스가 상위 클래스를 대체해도 프로그램이 올바르게 동작해야 한다는 원칙이다.

• 상위 클래스 객체 자리에 하위 클래스 객체를 넣어도 문제없이 작동해야 한다는 것은 이 원리의 정의이다.
• 상위 클래스를 추상 클래스와 추상 메소드로 정의해 하위 클래스가 이를 구현하게 하는 것은 교체 가능성을 확보하는 설계 방법으로 설명된다.
• 하위 클래스가 상위 클래스의 책임을 무시하지 않고 확장만 해야 한다는 것은 교체 가능성을 지키기 위한 조건이다.

파스칼 케이스는 StudentName, 카멜 케이스는 studentName, 스네이크 케이스는 student_name과 연결된다.

파스칼 케이스는 모든 단어의 첫 글자를 대문자로, 카멜 케이스는 첫 단어는 소문자로 시작하고 이후 단어의 첫 글자만 대문자로 쓴다.

• 스네이크 케이스는 단어를 밑줄(_)로 연결하므로 대문자 표기 예시와 연결되지 않는다.
• 카멜 케이스는 첫 글자가 소문자이므로 첫 글자가 대문자인 예시와 연결되지 않는다.

50은 어느 구간의 경계에도 해당하지 않는 구간 내부 값이므로 경계값 분석의 입력값에 포함되지 않는다.

경계값 분석은 각 구간의 경계(0, 60, 70, 100)와 그 바로 안팎의 값을 테스트한다.

• -1은 최솟값 0의 바로 아래 값으로 무효 경계 입력이다.
• 69는 보통 구간의 상한이자 우수 구간 경계 70의 바로 아래 값이다.
• 100은 우수 구간의 최댓값 경계이다.

조건문 전체가 참일 때와 거짓일 때의 분기를 각각 실행하는 것은 조건 검증기준이 아니라 결정(분기) 검증기준이다.

조건 검증기준은 결정문 안의 개별 조건식 각각이 참과 거짓을 최소 한 번씩 갖도록 테스트한다.

• 문장 검증기준은 모든 문장을 최소 한 번 실행하도록 하는 가장 약한 기준이다.
• 다중 조건 검증기준은 개별 조건식의 모든 참·거짓 조합을 테스트해 조건이 다른 조건에 가려지는 마스크 문제를 해결한다.
• 경로 검증기준은 코드의 독립 경로를 최소 한 번 실행하도록 하는 기준이다.

초기 단계는 프로세스 없음, 관리 단계는 품질 보증, 정의 단계는 통합된 프로젝트 관리, 정량적 관리 단계는 조직 차원의 프로세스 성과 관리, 최적화 단계는 근본 원인 분석과 연결된다.

관리 단계는 프로젝트 단위의 기본 관리, 정의 단계는 조직 표준 프로세스 정립, 정량적 관리 단계는 수치 기반 관리, 최적화 단계는 지속적 개선 활동이 중심이다.

• 초기 단계에 요구사항 관리를 연결한 조합은 틀렸다. 초기 단계는 정해진 프로세스가 없는 상태이고 요구사항 관리는 관리 단계 활동이다.
• 정의 단계에 품질 보증을 연결한 조합은 틀렸다. 품질 보증은 관리 단계 활동이다.