22년 1회차
○ WBS(Work Breakdown Structure)를 도구로 사용하고, WBS 체계에 따른 계층 구조와 최하위 항목인 작업 패키지가 결과로 산출된다.
인도물을 작은 구성 요소로 나누고 WBS를 산출하는 프로세스는 범위 정의이다.
범위 관리는 범위 기획 → 범위 정의 → 범위 검증 → 범위 변경 통제 순으로 진행되며, 범위 정의 단계에서 WBS와 최하위 작업 패키지가 만들어진다.
- 범위 기획: 범위를 어떻게 정의·검증·통제할지 계획하고 범위 기술서를 준비하는 단계이다.
- 범위 검증: 완성된 인도물을 이해관계자가 공식적으로 인수(승인)하는 단계이다.
- 범위 변경 통제: 범위 변경 요청을 검토·승인하고 기준선 변경을 관리하는 단계이다.
○ 프로젝트나 프로덕트가 특정 상태에 이르렀는지 나타낸다.
○ 계속되는 개발 또는 유지보수 작업의 기준이 된다.
○ 형상 항목에 대한 변경을 제어하는 메커니즘이다.
설명은 베이스라인(Baseline)에 해당한다.
베이스라인은 공식 검토·합의를 거친 형상 항목의 기준 시점으로, 이후 변경은 공식 변경 통제 절차를 거쳐야만 반영된다. 따라서 진행 상태의 이정표이자 후속 작업의 기준이 된다.
- VCS: 소스·문서의 이력과 버전을 저장·관리하는 도구로, 기준 상태를 정의하는 개념 자체는 아니다.
- CMMI: 조직 프로세스의 성숙도를 평가·개선하는 모델이다.
- CI: 개발자의 변경을 자주 통합하고 자동 빌드·테스트하는 실천법이다.
여러 운영 환경·플랫폼에서 실행되도록 변형 가능한 속성은 상호운용성이 아니라 이식성이다.
상호운용성은 다른 시스템·소프트웨어와 정보를 교환하고 함께 동작하는 능력을 뜻한다.
- 신뢰성: 요구 기능을 정확하고 일관되게 수행하는 속성으로 옳은 설명이다.
- 효율성: 최소의 시간·자원으로 결과를 내는 속성으로 옳은 설명이다.
- 모듈성: 컴포넌트 단위로 나뉘어 통합·조정·변경을 쉽게 하는 속성으로 옳은 설명이다.
성능·신뢰성·보안성·가용성 같은 품질 요소는 기능 요구사항이 아니라 비기능 요구사항이다.
유스케이스 명세서의 기능 요구사항은 시스템이 수행해야 할 동작(무엇을 하는가)을 기술한다.
- 개요: 유스케이스가 제공하는 기능과 이를 사용하는 액터를 요약한다.
- 이벤트 흐름: 액터와 시스템 간 대화를 문장이나 순차 다이어그램으로 표현한다.
- 후행 조건: 수행 완료 후 만족해야 할 상태·수치 변화를 구체적으로 기술한다.
적응성·설치용이성은 기능성이 아니라 이식성의 부특성이므로 기능성과의 짝이 잘못되었다.
ISO/IEC 9126의 기능성 부특성은 적합성, 정확성, 상호운용성, 보안성, 준수성이다.
- 신뢰성: 성숙성, 결함허용성, 회복성으로 옳게 짝지어졌다.
- 유지보수성: 분석성, 변경성, 안정성은 시험성과 함께 유지보수성의 부특성이므로 옳게 짝지어졌다.
- 사용성: 이해성, 학습용이성, 운영성으로 옳게 짝지어졌다.
액터끼리도 일반화(상속) 관계를 맺을 수 있으므로 액터들이 서로 관계를 형성하지 않는다는 설명은 옳지 않다.
예를 들어 일반 회원 액터를 특수화한 우수 회원 액터처럼 공통 역할을 상위 액터로 묶어 표현한다.
- 외부 시스템: 시스템과 상호작용하는 외부 시스템도 액터로 표현한다.
- include 관계: 여러 유스케이스가 공통으로 반드시 호출하는 기능을 분리할 때 쓴다.
- extend 관계: 특정 조건에서만 수행되는 선택적 기능을 확장으로 표현할 때 쓴다.
MVC는 화면과 데이터를 분리하므로 사용자 인터페이스(뷰)가 바뀌어도 모델은 영향을 받지 않는다.
이 관심사 분리 덕분에 같은 모델에 여러 뷰를 붙이거나 뷰만 교체할 수 있다.
- 뷰: 모델의 처리 결과를 사용자에게 보여준다.
- 컨트롤러: 사용자 요청을 받아 모델에 전달하고 흐름을 제어한다.
- 모델: 데이터와 비즈니스 로직을 관리하고 변경 시 뷰에 통지한다.
class (가):(가) (나) (다) (라)
def __init__(self, name, price):
self.name = name
self.price = price
def (나)(self):
print("{}'s price = {}".format(self.name,
self.price))
class (다)((가)):
def __init__(self, name, price):
Food.__init__(self, name, price)
def (라)(self):
print("{}".format(self.name))
클래스 다이어그램에서 Food 가 부모 클래스, Korean 이 Food 를 상속한 자식 클래스이므로 (가) Food, (나) show, (다) Korean, (라) showname 이 들어간다.
Food 는 name·price 속성과 show() 연산을 가지며, 코드에서 이름과 가격을 함께 출력하는 메서드가 show 이다. Korean 은 속이 빈 삼각형 화살표(일반화)로 Food 를 가리키므로 파이썬에서는 class Korean(Food) 로 표현하고, 생성자에서 Food.__init__ 을 호출한다. Korean 에만 있는 showname() 이 이름만 출력하는 메서드이다.
- Korean·showname·Food·show 구성: 상속 방향이 거꾸로이고 두 메서드의 위치도 뒤바뀌어, 자식 생성자의 Food.__init__ 호출과 맞지 않는다.
- Food·showname·Korean·show 구성: 부모에 showname, 자식에 show 를 두는 것이라 다이어그램의 연산 배치와 반대이다.
- Korean·show·Food·showname 구성: 메서드 이름은 맞지만 Korean 이 부모가 되어 상속 방향이 반대이다.
이 구조는 데코레이터(Decorator) 패턴이다.
Line 은 Display 를 상속하면서 동시에 Display 객체를 집약(속이 빈 마름모)으로 참조한다. 즉 같은 타입을 상속하면서 그 타입을 감싸는 장식자이며, TextDisplay 는 실제 구성요소, SingleLine·DoubleLine 은 구체 장식자로서 기능을 겹겹이 덧붙일 수 있다.
- 메멘토 패턴: 객체의 내부 상태를 저장해 두었다가 복원하는 행위 패턴으로 Originator·Memento·Caretaker 구조이다.
- 어댑터 패턴: 호환되지 않는 인터페이스를 변환하는 구조로, 감싸는 대상과 같은 타입을 상속하지 않는다.
- 빌더 패턴: 복잡한 객체의 생성 과정을 단계별로 분리하는 생성 패턴이다.
ㄴ. 경로 테스팅
ㄷ. 상태기반 테스팅
ㄹ. 원인 결과 그래프
화이트박스 테스트는 제어 흐름 테스팅과 경로 테스팅이다.
화이트박스 기법은 코드 내부 구조(제어 흐름·경로)를 근거로, 블랙박스 기법은 명세(입출력·상태)를 근거로 테스트 케이스를 만든다.
- 제어 흐름 테스팅: 제어 흐름 그래프의 문장·분기를 덮도록 설계하는 화이트박스 기법이다.
- 경로 테스팅: 기초 경로 등 실행 경로를 기준으로 하는 화이트박스 기법이다.
- 상태기반 테스팅: 명세의 상태 전이도를 근거로 하는 블랙박스 기법이다.
- 원인 결과 그래프: 입력 조건(원인)과 출력(결과)의 논리 관계를 근거로 하는 블랙박스 기법이다.
옳은 자료 흐름도는 판매자·고객을 사각형(외부 개체), 음식등록·음식구매를 원(프로세스), 등록음식을 평행한 두 선(자료 저장소)으로 그린 것이다.
Yourdon/DeMarco 표기법에서 프로세스는 원, 외부 개체(터미네이터)는 사각형, 자료 저장소는 위아래 두 줄의 평행선, 자료 흐름은 이름 붙은 화살표로 나타낸다.
- 등록음식을 사각형으로 그린 도식: 자료 저장소를 외부 개체 기호로 표현해 틀렸다.
- 판매자·고객을 평행선으로 그린 도식: 외부 개체를 자료 저장소 기호로 표현해 틀렸다.
- 판매자·고객을 원, 음식등록·음식구매를 사각형으로 그린 도식: 외부 개체와 프로세스의 기호가 서로 뒤바뀌었다.
사이클로매틱 복잡성은 절차적 코드의 제어 흐름 복잡도 척도로, 객체지향 전용 품질 척도(CK 메트릭)에 속하지 않는다.
CK 메트릭은 WMC, DIT, NOC, CBO, RFC, LCOM의 여섯 가지로 클래스 구조·상속·결합·응집을 측정한다.
- 클래스 당 가중치를 갖는 메소드(WMC): 클래스 메소드 복잡도의 합으로 CK 메트릭이다.
- 상속 트리의 깊이(DIT): 클래스의 상속 계층 깊이로 CK 메트릭이다.
- 메소드의 응집 결핍(LCOM): 메소드 간 응집 부족 정도로 CK 메트릭이다.
수집한 요구사항은 프로그래밍 언어가 아니라 자연어·모델링 표기(UML 등)로 기술한다.
요구사항 명세는 고객·사용자도 이해하고 검토할 수 있어야 하며, 구현 방법(어떻게)이 아닌 시스템이 할 일(무엇을)을 담아야 한다.
- 프로토타입: 일부 기능을 빠르게 구현해 요구를 구체화하는 도출 기법이다.
- 브레인스토밍: 이해관계자가 모여 다양한 요구를 끌어내는 도출 기법이다.
- 현행 시스템 조사: 관련 직원 인터뷰·자료 수집으로 문제점을 파악하는 도출 기법이다.
생명주기 중 시간과 비용이 가장 많이 드는 단계는 개발단계가 아니라 유지보수 단계이다.
소프트웨어는 운영 기간 동안 수정·적응·개선이 계속되므로 전체 비용에서 유지보수 비중이 가장 크다.
- 개발방법론의 바탕: 방법론은 생명주기 모델을 기반으로 활동과 산출물을 정의한다.
- 단계 구분: 일반적으로 정의–개발–유지보수 단계로 나눈다.
- 계획의 골격: 단계별 활동이 비용 산정과 개발 계획 수립의 기준이 된다.
| 평가 점수 | 등급 |
|---|---|
| 90점 이상부터 100점 이하 | A |
| 80점 이상부터 90점 미만 | B |
| 70점 이상부터 80점 미만 | C |
| 60점 이상부터 70점 미만 | D |
| 0점 이상부터 60점 미만 | F |
경곗값마다 경계 바로 아래·경계·바로 위 값을 고르면 테스트 케이스는 18개이다.
등급이 바뀌는 경계점은 0, 60, 70, 80, 90, 100의 6개이고, 점수가 정수이므로 각 경계점에서 3개씩 고른다.
-1, 0, 1 / 59, 60, 61 / 69, 70, 71 / 79, 80, 81 / 89, 90, 91 / 99, 100, 101
○ Builder ○ Composite ○ Decorator
○ Iterator ○ Mediator ○ Observer
○ Prototype ○ Proxy ○ Singleton
○ Strategy ○ Visitor
생성 패턴 4개, 구조 패턴 5개, 행위 패턴 5개이다.
- 생성 패턴: Abstract Factory, Builder, Prototype, Singleton
- 구조 패턴: Adapter, Bridge, Composite, Decorator, Proxy
- 행위 패턴: Iterator, Mediator, Observer, Strategy, Visitor
생성은 객체 생성 방식, 구조는 클래스·객체의 조합, 행위는 객체 간 상호작용과 책임 분배를 다룬다.
표준으로 정의된 프로세스를 사용하는 것은 관리단계가 아니라 확립단계의 특징이다.
SPICE 능력 수준은 불완전 → 수행 → 관리 → 확립 → 예측 → 최적화 순이며, 관리단계는 프로세스가 계획·추적·관리되고 산출물이 통제되는 수준이다.
- 수행단계: 프로세스 목적은 달성하지만 계획·추적은 이루어지지 않는다.
- 예측단계: 프로세스를 정량적으로 측정·관리해 결과를 예측할 수 있다.
- 최적화 단계: 프로세스가 지속적으로 개선·최적화된다.
<보기 2>
적용된 설계 원칙은 개방 폐쇄의 원칙(OCP)이다.
적용 전에는 학과평균점수 클래스 안에 학과마다 메서드가 나열되어 있어 학과가 늘 때마다 이 클래스를 고쳐야 한다. 적용 후에는 학과라는 상위 타입에 평균계산()을 두고 학과별 하위 클래스가 이를 구현하므로, 새 학과는 기존 코드 수정 없이 하위 클래스 추가로 확장된다.
- 의존 관계 역전의 원칙: 상위 모듈과 하위 모듈이 모두 추상에 의존하게 하는 원칙으로, 이 사례가 보여 주는 핵심인 수정 없는 확장과는 초점이 다르다.
- 인터페이스 분리의 원칙: 비대한 인터페이스를 클라이언트별로 쪼개는 원칙인데, 여기서는 인터페이스를 나누지 않았다.
- 단일 책임 원칙: 한 클래스가 하나의 책임만 갖게 하는 원칙으로, 적용 전 클래스도 평균 계산이라는 한 역할만 맡고 있었다.
class Person { ... }
class Work { ... }
interface PublicService {
public void doWork(Work work);
}
class Official extends Person implements PublicService {
public void sayHello() { ... }
public void doWork(Work work) { ... }
...
}
다이어그램에 나타나지 않는 관계는 속이 빈 마름모가 달린 실선, 즉 집약(aggregation)이다.
코드에는 Work 를 필드로 보관하는 등 전체-부분 관계가 없다. Work 는 doWork 메서드의 매개변수로만 쓰이므로 의존 관계로 그려진다.
- 점선 열린 화살표(의존): Official·PublicService 가 doWork(Work work) 의 매개변수로 Work 를 사용하므로 나타난다.
- 점선 빈 삼각형 화살표(실체화): Official 이 PublicService 인터페이스를 implements 하므로 나타난다.
- 실선 빈 삼각형 화살표(일반화): Official 이 Person 을 extends 하므로 나타난다.
MC/DC를 달성하면 각 조건이 참·거짓을 모두 취하므로 조건 커버리지도 달성된다.
MC/DC는 조건 커버리지와 분기 커버리지를 모두 포함하면서, 각 조건이 독립적으로 결정 결과에 영향을 주는지까지 확인한다.
- 문장 커버리지: 모든 문장을 한 번 이상 실행하는 기준이며, 입력 유형 적합성 검증과는 무관하다.
- 분기 → 조건: 분기 결과만 참·거짓을 덮어도 개별 조건이 모든 값을 취하지 않을 수 있다.
- 조건 → 분기: 개별 조건이 참·거짓을 모두 취해도 전체 결정이 한쪽 결과만 나올 수 있다.
프로젝트 비용을 예측하는 데 쓰는 것은 COCOMO이다.
COCOMO는 예상 코드 규모(KLOC)와 보정 계수로 노력(MM)·기간·비용을 추정하는 모델이다.
- 기능 점수: 기능의 정확성 검증이 아니라 소프트웨어 규모·비용 산정 기법이다.
- 폭포수 모형: 단계를 순차 진행하므로 요구 변경 대응에 취약하다.
- CMMI: 일정 계획 기법이 아니라 조직 프로세스 성숙도 평가·개선 모델이다.
<표 1>
| 인자 | |||
|---|---|---|---|
| A | B | C | |
| 값 | A1 | B1 | C1 |
| A2 | B2 | C2 | |
| A3 | |||
| A | B | C |
|---|---|---|
| A1 | B1 | C1 |
| A1 | B2 | C2 |
| A2 | (가) | C1 |
| A2 | (나) | C2 |
| A3 | (다) | C1 |
| A3 | (라) | C2 |
(가)~(라)에는 B1, B2, B2, B1이 들어가야 모든 인자 쌍이 한 번 이상 나타난다.
A–B 쌍을 위해 A2와 A3는 각각 B1·B2를 한 번씩 가져야 하고, 기존 행에 B1–C1, B2–C2만 있으므로 B1–C2, B2–C1을 추가로 덮어야 한다.
- (가) B1, (나) B2: A2–B1, A2–B2를 덮는다.
- (다) B2: A3–B2와 B2–C1을 덮는다.
- (라) B1: A3–B1과 B1–C2를 덮는다.
B1, B2, B1, B2 순으로 넣으면 B1–C2, B2–C1 쌍이 빠지고, 같은 A에 같은 B를 두 번 넣으면 A–B 쌍이 빠진다.
총 투입 공수는 111 MM이다.
기존 인력: 6명이 16개월 전부 투입
추가 인력: 11개월 시작부터 16개월까지 6개월 투입
int A(){
int a;
...
B(a);
...
}
int B(int x){
...
if(x > 0)
/* send data */
else
/* receive data */
}A가 넘긴 값 x가 B의 실행 흐름(송신/수신)을 결정하므로 제어 결합이다.
제어 결합은 한 모듈이 다른 모듈의 내부 논리 흐름을 제어하는 플래그를 전달하는 결합으로, 호출하는 쪽이 피호출 모듈의 내부 동작을 알아야 한다.
- 내용 결합: 다른 모듈의 내부 데이터나 코드를 직접 참조·변경하는 결합이다.
- 자료 결합: 계산에 필요한 단순 데이터만 전달할 뿐 흐름을 제어하지 않는 결합이다.
- 스탬프 결합: 배열·구조체 같은 자료 구조 전체를 전달하는 결합이다.
○ WBS(Work Breakdown Structure)를 도구로 사용하고, WBS 체계에 따른 계층 구조와 최하위 항목인 작업 패키지가 결과로 산출된다.
인도물을 작은 구성 요소로 나누고 WBS를 산출하는 프로세스는 범위 정의이다.
범위 관리는 범위 기획 → 범위 정의 → 범위 검증 → 범위 변경 통제 순으로 진행되며, 범위 정의 단계에서 WBS와 최하위 작업 패키지가 만들어진다.
- 범위 기획: 범위를 어떻게 정의·검증·통제할지 계획하고 범위 기술서를 준비하는 단계이다.
- 범위 검증: 완성된 인도물을 이해관계자가 공식적으로 인수(승인)하는 단계이다.
- 범위 변경 통제: 범위 변경 요청을 검토·승인하고 기준선 변경을 관리하는 단계이다.
○ 프로젝트나 프로덕트가 특정 상태에 이르렀는지 나타낸다.
○ 계속되는 개발 또는 유지보수 작업의 기준이 된다.
○ 형상 항목에 대한 변경을 제어하는 메커니즘이다.
설명은 베이스라인(Baseline)에 해당한다.
베이스라인은 공식 검토·합의를 거친 형상 항목의 기준 시점으로, 이후 변경은 공식 변경 통제 절차를 거쳐야만 반영된다. 따라서 진행 상태의 이정표이자 후속 작업의 기준이 된다.
- VCS: 소스·문서의 이력과 버전을 저장·관리하는 도구로, 기준 상태를 정의하는 개념 자체는 아니다.
- CMMI: 조직 프로세스의 성숙도를 평가·개선하는 모델이다.
- CI: 개발자의 변경을 자주 통합하고 자동 빌드·테스트하는 실천법이다.
여러 운영 환경·플랫폼에서 실행되도록 변형 가능한 속성은 상호운용성이 아니라 이식성이다.
상호운용성은 다른 시스템·소프트웨어와 정보를 교환하고 함께 동작하는 능력을 뜻한다.
- 신뢰성: 요구 기능을 정확하고 일관되게 수행하는 속성으로 옳은 설명이다.
- 효율성: 최소의 시간·자원으로 결과를 내는 속성으로 옳은 설명이다.
- 모듈성: 컴포넌트 단위로 나뉘어 통합·조정·변경을 쉽게 하는 속성으로 옳은 설명이다.
성능·신뢰성·보안성·가용성 같은 품질 요소는 기능 요구사항이 아니라 비기능 요구사항이다.
유스케이스 명세서의 기능 요구사항은 시스템이 수행해야 할 동작(무엇을 하는가)을 기술한다.
- 개요: 유스케이스가 제공하는 기능과 이를 사용하는 액터를 요약한다.
- 이벤트 흐름: 액터와 시스템 간 대화를 문장이나 순차 다이어그램으로 표현한다.
- 후행 조건: 수행 완료 후 만족해야 할 상태·수치 변화를 구체적으로 기술한다.
적응성·설치용이성은 기능성이 아니라 이식성의 부특성이므로 기능성과의 짝이 잘못되었다.
ISO/IEC 9126의 기능성 부특성은 적합성, 정확성, 상호운용성, 보안성, 준수성이다.
- 신뢰성: 성숙성, 결함허용성, 회복성으로 옳게 짝지어졌다.
- 유지보수성: 분석성, 변경성, 안정성은 시험성과 함께 유지보수성의 부특성이므로 옳게 짝지어졌다.
- 사용성: 이해성, 학습용이성, 운영성으로 옳게 짝지어졌다.
액터끼리도 일반화(상속) 관계를 맺을 수 있으므로 액터들이 서로 관계를 형성하지 않는다는 설명은 옳지 않다.
예를 들어 일반 회원 액터를 특수화한 우수 회원 액터처럼 공통 역할을 상위 액터로 묶어 표현한다.
- 외부 시스템: 시스템과 상호작용하는 외부 시스템도 액터로 표현한다.
- include 관계: 여러 유스케이스가 공통으로 반드시 호출하는 기능을 분리할 때 쓴다.
- extend 관계: 특정 조건에서만 수행되는 선택적 기능을 확장으로 표현할 때 쓴다.
MVC는 화면과 데이터를 분리하므로 사용자 인터페이스(뷰)가 바뀌어도 모델은 영향을 받지 않는다.
이 관심사 분리 덕분에 같은 모델에 여러 뷰를 붙이거나 뷰만 교체할 수 있다.
- 뷰: 모델의 처리 결과를 사용자에게 보여준다.
- 컨트롤러: 사용자 요청을 받아 모델에 전달하고 흐름을 제어한다.
- 모델: 데이터와 비즈니스 로직을 관리하고 변경 시 뷰에 통지한다.
class (가):(가) (나) (다) (라)
def __init__(self, name, price):
self.name = name
self.price = price
def (나)(self):
print("{}'s price = {}".format(self.name,
self.price))
class (다)((가)):
def __init__(self, name, price):
Food.__init__(self, name, price)
def (라)(self):
print("{}".format(self.name))
클래스 다이어그램에서 Food 가 부모 클래스, Korean 이 Food 를 상속한 자식 클래스이므로 (가) Food, (나) show, (다) Korean, (라) showname 이 들어간다.
Food 는 name·price 속성과 show() 연산을 가지며, 코드에서 이름과 가격을 함께 출력하는 메서드가 show 이다. Korean 은 속이 빈 삼각형 화살표(일반화)로 Food 를 가리키므로 파이썬에서는 class Korean(Food) 로 표현하고, 생성자에서 Food.__init__ 을 호출한다. Korean 에만 있는 showname() 이 이름만 출력하는 메서드이다.
- Korean·showname·Food·show 구성: 상속 방향이 거꾸로이고 두 메서드의 위치도 뒤바뀌어, 자식 생성자의 Food.__init__ 호출과 맞지 않는다.
- Food·showname·Korean·show 구성: 부모에 showname, 자식에 show 를 두는 것이라 다이어그램의 연산 배치와 반대이다.
- Korean·show·Food·showname 구성: 메서드 이름은 맞지만 Korean 이 부모가 되어 상속 방향이 반대이다.
이 구조는 데코레이터(Decorator) 패턴이다.
Line 은 Display 를 상속하면서 동시에 Display 객체를 집약(속이 빈 마름모)으로 참조한다. 즉 같은 타입을 상속하면서 그 타입을 감싸는 장식자이며, TextDisplay 는 실제 구성요소, SingleLine·DoubleLine 은 구체 장식자로서 기능을 겹겹이 덧붙일 수 있다.
- 메멘토 패턴: 객체의 내부 상태를 저장해 두었다가 복원하는 행위 패턴으로 Originator·Memento·Caretaker 구조이다.
- 어댑터 패턴: 호환되지 않는 인터페이스를 변환하는 구조로, 감싸는 대상과 같은 타입을 상속하지 않는다.
- 빌더 패턴: 복잡한 객체의 생성 과정을 단계별로 분리하는 생성 패턴이다.
ㄴ. 경로 테스팅
ㄷ. 상태기반 테스팅
ㄹ. 원인 결과 그래프
화이트박스 테스트는 제어 흐름 테스팅과 경로 테스팅이다.
화이트박스 기법은 코드 내부 구조(제어 흐름·경로)를 근거로, 블랙박스 기법은 명세(입출력·상태)를 근거로 테스트 케이스를 만든다.
- 제어 흐름 테스팅: 제어 흐름 그래프의 문장·분기를 덮도록 설계하는 화이트박스 기법이다.
- 경로 테스팅: 기초 경로 등 실행 경로를 기준으로 하는 화이트박스 기법이다.
- 상태기반 테스팅: 명세의 상태 전이도를 근거로 하는 블랙박스 기법이다.
- 원인 결과 그래프: 입력 조건(원인)과 출력(결과)의 논리 관계를 근거로 하는 블랙박스 기법이다.
옳은 자료 흐름도는 판매자·고객을 사각형(외부 개체), 음식등록·음식구매를 원(프로세스), 등록음식을 평행한 두 선(자료 저장소)으로 그린 것이다.
Yourdon/DeMarco 표기법에서 프로세스는 원, 외부 개체(터미네이터)는 사각형, 자료 저장소는 위아래 두 줄의 평행선, 자료 흐름은 이름 붙은 화살표로 나타낸다.
- 등록음식을 사각형으로 그린 도식: 자료 저장소를 외부 개체 기호로 표현해 틀렸다.
- 판매자·고객을 평행선으로 그린 도식: 외부 개체를 자료 저장소 기호로 표현해 틀렸다.
- 판매자·고객을 원, 음식등록·음식구매를 사각형으로 그린 도식: 외부 개체와 프로세스의 기호가 서로 뒤바뀌었다.
사이클로매틱 복잡성은 절차적 코드의 제어 흐름 복잡도 척도로, 객체지향 전용 품질 척도(CK 메트릭)에 속하지 않는다.
CK 메트릭은 WMC, DIT, NOC, CBO, RFC, LCOM의 여섯 가지로 클래스 구조·상속·결합·응집을 측정한다.
- 클래스 당 가중치를 갖는 메소드(WMC): 클래스 메소드 복잡도의 합으로 CK 메트릭이다.
- 상속 트리의 깊이(DIT): 클래스의 상속 계층 깊이로 CK 메트릭이다.
- 메소드의 응집 결핍(LCOM): 메소드 간 응집 부족 정도로 CK 메트릭이다.
수집한 요구사항은 프로그래밍 언어가 아니라 자연어·모델링 표기(UML 등)로 기술한다.
요구사항 명세는 고객·사용자도 이해하고 검토할 수 있어야 하며, 구현 방법(어떻게)이 아닌 시스템이 할 일(무엇을)을 담아야 한다.
- 프로토타입: 일부 기능을 빠르게 구현해 요구를 구체화하는 도출 기법이다.
- 브레인스토밍: 이해관계자가 모여 다양한 요구를 끌어내는 도출 기법이다.
- 현행 시스템 조사: 관련 직원 인터뷰·자료 수집으로 문제점을 파악하는 도출 기법이다.
생명주기 중 시간과 비용이 가장 많이 드는 단계는 개발단계가 아니라 유지보수 단계이다.
소프트웨어는 운영 기간 동안 수정·적응·개선이 계속되므로 전체 비용에서 유지보수 비중이 가장 크다.
- 개발방법론의 바탕: 방법론은 생명주기 모델을 기반으로 활동과 산출물을 정의한다.
- 단계 구분: 일반적으로 정의–개발–유지보수 단계로 나눈다.
- 계획의 골격: 단계별 활동이 비용 산정과 개발 계획 수립의 기준이 된다.
| 평가 점수 | 등급 |
|---|---|
| 90점 이상부터 100점 이하 | A |
| 80점 이상부터 90점 미만 | B |
| 70점 이상부터 80점 미만 | C |
| 60점 이상부터 70점 미만 | D |
| 0점 이상부터 60점 미만 | F |
경곗값마다 경계 바로 아래·경계·바로 위 값을 고르면 테스트 케이스는 18개이다.
등급이 바뀌는 경계점은 0, 60, 70, 80, 90, 100의 6개이고, 점수가 정수이므로 각 경계점에서 3개씩 고른다.
-1, 0, 1 / 59, 60, 61 / 69, 70, 71 / 79, 80, 81 / 89, 90, 91 / 99, 100, 101
○ Builder ○ Composite ○ Decorator
○ Iterator ○ Mediator ○ Observer
○ Prototype ○ Proxy ○ Singleton
○ Strategy ○ Visitor
생성 패턴 4개, 구조 패턴 5개, 행위 패턴 5개이다.
- 생성 패턴: Abstract Factory, Builder, Prototype, Singleton
- 구조 패턴: Adapter, Bridge, Composite, Decorator, Proxy
- 행위 패턴: Iterator, Mediator, Observer, Strategy, Visitor
생성은 객체 생성 방식, 구조는 클래스·객체의 조합, 행위는 객체 간 상호작용과 책임 분배를 다룬다.
표준으로 정의된 프로세스를 사용하는 것은 관리단계가 아니라 확립단계의 특징이다.
SPICE 능력 수준은 불완전 → 수행 → 관리 → 확립 → 예측 → 최적화 순이며, 관리단계는 프로세스가 계획·추적·관리되고 산출물이 통제되는 수준이다.
- 수행단계: 프로세스 목적은 달성하지만 계획·추적은 이루어지지 않는다.
- 예측단계: 프로세스를 정량적으로 측정·관리해 결과를 예측할 수 있다.
- 최적화 단계: 프로세스가 지속적으로 개선·최적화된다.
<보기 2>
적용된 설계 원칙은 개방 폐쇄의 원칙(OCP)이다.
적용 전에는 학과평균점수 클래스 안에 학과마다 메서드가 나열되어 있어 학과가 늘 때마다 이 클래스를 고쳐야 한다. 적용 후에는 학과라는 상위 타입에 평균계산()을 두고 학과별 하위 클래스가 이를 구현하므로, 새 학과는 기존 코드 수정 없이 하위 클래스 추가로 확장된다.
- 의존 관계 역전의 원칙: 상위 모듈과 하위 모듈이 모두 추상에 의존하게 하는 원칙으로, 이 사례가 보여 주는 핵심인 수정 없는 확장과는 초점이 다르다.
- 인터페이스 분리의 원칙: 비대한 인터페이스를 클라이언트별로 쪼개는 원칙인데, 여기서는 인터페이스를 나누지 않았다.
- 단일 책임 원칙: 한 클래스가 하나의 책임만 갖게 하는 원칙으로, 적용 전 클래스도 평균 계산이라는 한 역할만 맡고 있었다.
class Person { ... }
class Work { ... }
interface PublicService {
public void doWork(Work work);
}
class Official extends Person implements PublicService {
public void sayHello() { ... }
public void doWork(Work work) { ... }
...
}다이어그램에 나타나지 않는 관계는 속이 빈 마름모가 달린 실선, 즉 집약(aggregation)이다.
코드에는 Work 를 필드로 보관하는 등 전체-부분 관계가 없다. Work 는 doWork 메서드의 매개변수로만 쓰이므로 의존 관계로 그려진다.
- 점선 열린 화살표(의존): Official·PublicService 가 doWork(Work work) 의 매개변수로 Work 를 사용하므로 나타난다.
- 점선 빈 삼각형 화살표(실체화): Official 이 PublicService 인터페이스를 implements 하므로 나타난다.
- 실선 빈 삼각형 화살표(일반화): Official 이 Person 을 extends 하므로 나타난다.
MC/DC를 달성하면 각 조건이 참·거짓을 모두 취하므로 조건 커버리지도 달성된다.
MC/DC는 조건 커버리지와 분기 커버리지를 모두 포함하면서, 각 조건이 독립적으로 결정 결과에 영향을 주는지까지 확인한다.
- 문장 커버리지: 모든 문장을 한 번 이상 실행하는 기준이며, 입력 유형 적합성 검증과는 무관하다.
- 분기 → 조건: 분기 결과만 참·거짓을 덮어도 개별 조건이 모든 값을 취하지 않을 수 있다.
- 조건 → 분기: 개별 조건이 참·거짓을 모두 취해도 전체 결정이 한쪽 결과만 나올 수 있다.
프로젝트 비용을 예측하는 데 쓰는 것은 COCOMO이다.
COCOMO는 예상 코드 규모(KLOC)와 보정 계수로 노력(MM)·기간·비용을 추정하는 모델이다.
- 기능 점수: 기능의 정확성 검증이 아니라 소프트웨어 규모·비용 산정 기법이다.
- 폭포수 모형: 단계를 순차 진행하므로 요구 변경 대응에 취약하다.
- CMMI: 일정 계획 기법이 아니라 조직 프로세스 성숙도 평가·개선 모델이다.
<표 1>
| 인자 | |||
|---|---|---|---|
| A | B | C | |
| 값 | A1 | B1 | C1 |
| A2 | B2 | C2 | |
| A3 | |||
| A | B | C |
|---|---|---|
| A1 | B1 | C1 |
| A1 | B2 | C2 |
| A2 | (가) | C1 |
| A2 | (나) | C2 |
| A3 | (다) | C1 |
| A3 | (라) | C2 |
(가)~(라)에는 B1, B2, B2, B1이 들어가야 모든 인자 쌍이 한 번 이상 나타난다.
A–B 쌍을 위해 A2와 A3는 각각 B1·B2를 한 번씩 가져야 하고, 기존 행에 B1–C1, B2–C2만 있으므로 B1–C2, B2–C1을 추가로 덮어야 한다.
- (가) B1, (나) B2: A2–B1, A2–B2를 덮는다.
- (다) B2: A3–B2와 B2–C1을 덮는다.
- (라) B1: A3–B1과 B1–C2를 덮는다.
B1, B2, B1, B2 순으로 넣으면 B1–C2, B2–C1 쌍이 빠지고, 같은 A에 같은 B를 두 번 넣으면 A–B 쌍이 빠진다.
총 투입 공수는 111 MM이다.
기존 인력: 6명이 16개월 전부 투입
추가 인력: 11개월 시작부터 16개월까지 6개월 투입
int A(){
int a;
...
B(a);
...
}
int B(int x){
...
if(x > 0)
/* send data */
else
/* receive data */
}A가 넘긴 값 x가 B의 실행 흐름(송신/수신)을 결정하므로 제어 결합이다.
제어 결합은 한 모듈이 다른 모듈의 내부 논리 흐름을 제어하는 플래그를 전달하는 결합으로, 호출하는 쪽이 피호출 모듈의 내부 동작을 알아야 한다.
- 내용 결합: 다른 모듈의 내부 데이터나 코드를 직접 참조·변경하는 결합이다.
- 자료 결합: 계산에 필요한 단순 데이터만 전달할 뿐 흐름을 제어하지 않는 결합이다.
- 스탬프 결합: 배열·구조체 같은 자료 구조 전체를 전달하는 결합이다.