임베디드기사 필기 14 — 임베디드 소프트웨어 ③ 개발방법론(UML·테스트·럼바우·나선형·CMMI)

임베디드기사 필기 14 — 임베디드 소프트웨어 ③ 개발방법론(UML·테스트·럼바우·나선형·CMMI)

4과목 [4-3] 개발방법론 파트입니다.
나선형 모형 제안자, 화이트박스 vs 블랙박스, CMMI 5단계는 매 회차 출제돼요.

---

소프트웨어 개발 단계 ⭐

요구사항 분석 — 시스템에 요구되는 사항 정의
설계          — 어떻게 만들지 명세
구현(Implementation) — 설계 명세서에 따라 컴퓨터가 이해할 수 있는 형태로 변환하는 프로그래밍/코딩 과정 ⭐
테스트        — 요구사항 만족 여부 검증

 

기출 문제

Q. 소프트웨어 개발에서 "구현"에 대한 설명으로 가장 적합한 것은?

A. 설계 명세서에 따라 컴퓨터가 이해할 수 있는 모습으로 변환되는 프로그래밍 또는 코딩 과정

---

소프트웨어 생명주기 모형 ⭐⭐⭐

 

폭포수 모형 (Waterfall)

요구사항 → 설계 → 구현 → 테스트 → 유지보수
순차적 진행, 이전 단계로 되돌아가기 어려움

 

프로토타이핑 모형 (Prototyping) ⭐⭐

핵심 기능만 담은 시제품(프로토타입) 먼저 제작
사용자 피드백 받아 요구사항 구체화

장점: 사용자 요구사항을 충실히 반영
      개발 초기에 오류 발견 가능!

⚠️ "개발 완료 시에야 최초로 오류 발견 가능" → 오답!
   (개발 초기에 발견 가능이 장점)

 

나선형 모형 (Spiral) ⭐⭐⭐

제안자: Boehm(보엠) ← 자주 출제!
특징: 계획→위험분석→개발→고객평가 반복
      비선형·반복적 개발
      대규모·고위험 시스템에 적합

⚠️ "Grady가 제안" → 오답! (Boehm이 제안)
⚠️ "폭포수 모형의 일종" → 오답! (독자적 모형)

 

기출 문제

Q. 나선형 모형에 대한 설명으로 거리가 먼 것은?

A. "Grady가 제안한 것으로 폭포수 모델의 일종이다" — 제안자는 Boehm, 독자적 모형

---

소프트웨어 설계 원칙 ⭐⭐

결합도(Coupling) — 낮을수록 좋음 (모듈 간 독립성↑)
응집도(Cohesion) — 높을수록 좋음 (모듈 내 집중도↑)

바람직한 설계: 결합도↓ + 응집도↑

⚠️ "모듈 간 결합도를 높게 한다" → 오답!
⚠️ "두 모듈 간 상호 의존도를 강하게 한다" → 오답!

 

요구사항 분석 모델

객체 모델  — 정적 구조 표현
동적 모델  — 상태 변화 표현
기능 모델  — 처리 과정 표현

⚠️ "리스크 모델" → 요구사항 분석 모델 아님!

---

객체지향 분석 기법 ⭐⭐

방법론	특징
Booch	미시적·거시적 개발 프로세스 포함, 클래스·객체 식별, 클러스터링
럼바우(Rumbaugh/OMT)	객체·동적·기능 모델링 3가지 사용
Jacobson	Use Case(유스케이스) 중심
Coad·Yourdon	E-R 다이어그램 활용
Wirfs-Brock	분석과 설계 구분 없이 연속 처리

 

럼바우 모델링 3종 ⭐⭐:

객체 모델링 — 정적 구조
동적 모델링 — 상태 다이어그램으로 행위·상태 변화 기술 ⭐
기능 모델링 — 자료 흐름

 

기출 문제

Q. 미시적·거시적 개발 프로세스 포함, 클러스터링 작업을 수행하는 OOA 방법은?

A. Booch 방법

 

Q. 럼바우 기법에서 상태 다이어그램으로 시스템의 행위를 기술하는 것은?

A. 동적 모델링(Dynamic Modeling)

---

UML 다이어그램 ⭐⭐

다이어그램	분류	설명
클래스도(Class)	구조	객체 타입·관계 표현, OO의 중심
컴포넌트도(Component)	구조	논리적→물리적 모델 재배치
순서도(Sequence)	행위	객체 간 메시지 교환, 시간 순서
상태도(State)	행위	객체 상태 변화
유스케이스도(Use Case)	행위	시스템-사용자 상호작용

⚠️ "Durability Diagram" → UML 표준 다이어그램 아님!

 

기출 문제

Q. UML에서 객체지향 방법론의 중심이 되는 다이어그램은?

A. 클래스도(Class Diagram)

 

Q. UML 다이어그램이 아닌 것은?

A. Durability Diagram (실존하지 않는 명칭)

---

소프트웨어 테스팅 ⭐⭐⭐

화이트박스 vs 블랙박스

구분	관점	대표 기법
화이트박스	내부 로직·구조 기반	기초 경로, 제어 흐름, 루프 검사, 조건·문장·경로 검증
블랙박스	입력→출력 기능 기반	동치(동등) 분할, 경계값 분석, 원인-효과 그래프

화이트박스 기법 아닌 것: 오류 예측 검사 ⭐
  ⚠️ "오류 예측 검사=화이트박스 기법" → 오답!

블랙박스 기법 아닌 것: 기초 경로 검사 ⭐
  ⚠️ "기초 경로 검사=블랙박스 기법" → 오답!

화이트박스 검증 기준 아닌 것: 기능 검증 기준 ⭐
  (문장/경로/조건 검증 기준이 화이트박스)

"원시 프로그램의 논리적 구조를 커버하도록 설계"
  → 화이트박스의 정의
  → 블랙박스 설명 보기로 나오면 오답!

 

테스트 단계

단위 검사 → 통합 검사 → 시스템 검사 → 검증 검사

검증 검사(Validation Test) ⭐
  → 통합 검사 후 요구사항 명세서 기반
  → 형상 검사 + 알파 검사 + 베타 검사 포함

 

테스트 오라클:

테스트 실행 결과가 올바른지 판별하는 메커니즘

 

기출 문제

Q. 블랙박스 테스팅 기법에 해당하지 않는 것은?

A. 기초 경로 검사 (화이트박스 기법)

 

Q. 화이트박스 검사 기법에 해당되지 않는 것은?

A. 오류 예측 검사

 

Q. 검증 검사(Validation Test)에 포함되는 기법은?

A. 형상 검사, 알파 검사, 베타 검사

---

정형 기술 검토 (FTR) ⭐

개발자들이 모여 산출물의 결함을 찾는 검토 활동

지침:
  제품에 대한 검토 (개인 평가 아님)
  논쟁·반박 제한
  의제와 참가자 수 제한! ⭐

⚠️ "의제와 참가자 수를 제한하지 않는다" → 오답!

---

CMMI 성숙도 5단계 ⭐⭐

1단계 초기(Initial)         — 프로세스 없음, 개인 역량 의존
2단계 관리(Managed)         — 프로젝트 단위 관리
3단계 정의(Defined)         — 조직 차원 표준 프로세스 확립
4단계 정량적관리(Quantitatively) — 정량적 지표로 측정·통제
5단계 최적화(Optimizing)    — 지속적 프로세스 개선

---

ISO 9126 품질 특성

6대 특성: 기능성/신뢰성/사용성/효율성/유지보수성/이식성

기능성 하위 특성: 적합성/정확성/상호운용성/보안성
⚠️ "분석성" → 기능성 아님! (유지보수성의 하위 특성)

---

C 국제표준

ISO/IEC 9899 = C 언어 국제표준
C89/C90 = ISO/IEC 9899:1990
C99     = ISO/IEC 9899:1999
C11     = ISO/IEC 9899:2011

---

💡 실무에서는?

20년 인프라/보안 SI에서 CMMI는 공공 프로젝트 입찰 시 발주처가 요구하는 수준이에요. 나선형 모형은 대규모 보안 인프라 구축 프로젝트에서 위험 분석을 반복하며 진행하는 방식과 정확히 일치해요. 단위 테스트→통합 테스트→시스템 테스트는 보안 솔루션 개발에서 기본 프로세스예요.

---

핵심 정리

✅ 구현=설계명세서→코딩 과정
✅ 나선형=Boehm 제안 ("Grady"/"폭포수일종"=오답!)
✅ 프로토타이핑 장점=초기오류발견 ("완료시발견"=오답!)
✅ 결합도↓ / 응집도↑ ("결합도↑"=오답!)
✅ 요구사항분석모델=객체/동적/기능 ("리스크"=오답!)
✅ 럼바우 동적모델링=상태다이어그램으로 행위기술
✅ UML 클래스도=OO의 중심
✅ "Durability Diagram"=UML 아님!
✅ 화이트박스: 기초경로/루프/조건/문장/경로검증
✅ 블랙박스: 동치분할/경계값/원인-효과
✅ "오류예측검사"=화이트박스 아님!
✅ "기초경로검사"=블랙박스 아님!
✅ 검증검사=형상+알파+베타
✅ FTR 지침: 의제·참가자 수 제한! ("제한안함"=오답!)
✅ CMMI: 초기→관리→정의→정량→최적화
✅ 분석성=유지보수성 하위 (기능성 아님!)

 

다음 편에서는 계산형 집중 훈련으로 이어갑니다!