소프트웨어 공학¶
1. 개발 방법론¶
폭포수 모델 (Waterfall)¶
선형적으로 진행합니다. 이전 단계로 돌아가기 어렵습니다.
- 장점: 단계가 명확, 문서화 철저
- 단점: 요구사항 변경에 취약, 후반부 오류 발견 시 비용 증가
- 적합: 요구사항이 명확하고 변경이 거의 없는 프로젝트
프로토타입 모델¶
초기에 시제품(프로토타입)을 만들어 사용자 피드백을 반영합니다.
- 장점: 요구사항 불명확 시 유리, 사용자 만족도 높음
- 단점: 관리 어려움, 프로토타입이 최종 산출물로 오해받을 수 있음
나선형 모델 (Spiral)¶
계획 → 위험 분석 → 개발/테스트 → 평가를 반복합니다.
- 장점: 위험 관리 우수, 대규모 프로젝트에 적합
- 단점: 복잡하고 비용이 높음
애자일 (Agile)¶
짧은 반복 주기(스프린트)로 동작하는 소프트웨어를 지속적으로 제공합니다.
애자일 4가지 가치¶
- 프로세스/도구보다 개인과 상호작용
- 문서보다 동작하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획보다 변화에 대응
스크럼 (Scrum)¶
애자일 방법론의 대표적인 프레임워크입니다.
| 구성 요소 | 설명 |
|---|---|
| 스프린트 | 1~4주의 개발 반복 주기 |
| 제품 백로그 | 전체 기능 목록 (우선순위 정렬) |
| 스프린트 백로그 | 해당 스프린트에서 처리할 작업 목록 |
| 데일리 스크럼 | 매일 15분 진행 상황 공유 |
| 스프린트 리뷰 | 완성된 기능 시연 |
| 회고 | 프로세스 개선 논의 |
스크럼 역할¶
- 제품 책임자(PO): 제품 백로그 관리
- 스크럼 마스터: 팀의 장애 제거, 스크럼 코치
- 개발팀: 실제 개발 수행
2. UML (Unified Modeling Language)¶
다이어그램 종류¶
구조 다이어그램 (정적)
| 다이어그램 | 용도 |
|---|---|
| 클래스 다이어그램 | 클래스 구조와 관계 |
| 객체 다이어그램 | 특정 시점의 객체 상태 |
| 컴포넌트 다이어그램 | 시스템 컴포넌트 구성 |
| 배포 다이어그램 | 하드웨어/소프트웨어 배포 환경 |
행위 다이어그램 (동적)
| 다이어그램 | 용도 |
|---|---|
| 유스케이스 다이어그램 | 시스템 기능과 사용자 관계 |
| 시퀀스 다이어그램 | 객체 간 메시지 교환 순서 |
| 상태 다이어그램 | 객체의 상태 변화 |
| 활동 다이어그램 | 업무 흐름/알고리즘 |
클래스 다이어그램¶
┌──────────────────┐
│ ClassName │ ← 클래스명
├──────────────────┤
│ - name: String │ ← 속성 (접근제어자 타입)
│ + age: int │
├──────────────────┤
│ + getName(): str │ ← 메서드
│ - validate() │
└──────────────────┘
접근 제어자
| 기호 | 의미 |
|---|---|
+ |
public |
- |
private |
# |
protected |
~ |
package |
관계
| 관계 | 표기 | 설명 |
|---|---|---|
| 상속 | 빈 삼각형 화살표 | IS-A |
| 구현 | 점선 삼각형 화살표 | 인터페이스 구현 |
| 연관 | 실선 | HAS-A |
| 집합 | 흰 마름모 | 약한 포함 (부분이 독립적) |
| 합성 | 검은 마름모 | 강한 포함 (부분이 전체에 종속) |
| 의존 | 점선 화살표 | 일시적 사용 |
3. 디자인 패턴¶
생성 패턴 (Creational)¶
싱글톤 (Singleton)¶
- 인스턴스를 1개만 생성
- 사용: DB 연결, 로거, 설정 관리자
팩토리 메서드 (Factory Method)¶
- 객체 생성을 서브클래스에 위임
- 사용: 객체 생성 로직을 캡슐화할 때
빌더 (Builder)¶
- 복잡한 객체를 단계별로 생성
- 사용: 선택적 매개변수가 많을 때
구조 패턴 (Structural)¶
어댑터 (Adapter)¶
- 호환되지 않는 인터페이스를 연결
- 사용: 레거시 코드 통합
데코레이터 (Decorator)¶
- 객체에 동적으로 기능 추가
- 사용: 기능 확장 (상속 없이)
파사드 (Facade)¶
- 복잡한 서브시스템을 단순한 인터페이스로 제공
- 사용: 복잡성 숨기기
행동 패턴 (Behavioral)¶
전략 (Strategy)¶
- 알고리즘을 캡슐화하여 교체 가능하게 함
- 사용: 정렬 방식, 결제 방식 선택
옵저버 (Observer)¶
- 한 객체의 변화를 여러 객체에 자동 통보
- 사용: 이벤트 처리, MVC 패턴
템플릿 메서드 (Template Method)¶
- 알고리즘 골격을 정의하고 세부 단계는 서브클래스에서 구현
- 사용: 공통 로직 추출
4. 소프트웨어 테스트¶
테스트 레벨¶
| 테스트 | 범위 | 수행자 |
|---|---|---|
| 단위(Unit) | 개별 모듈/함수 | 개발자 |
| 통합(Integration) | 모듈 간 상호작용 | 개발자 |
| 시스템(System) | 전체 시스템 | QA팀 |
| 인수(Acceptance) | 사용자 요구사항 | 고객 |
테스트 기법¶
블랙박스 테스트¶
- 내부 구현을 모르고 입출력만 검증
- 기법: 동등 분할, 경계값 분석, 결정 테이블
화이트박스 테스트¶
- 내부 구현을 알고 테스트 (코드 기반)
- 기법: 기본 경로 테스트, 조건 커버리지
회귀 테스트 (Regression Test)¶
- 수정 후 기존 기능이 정상 동작하는지 확인
코드 커버리지¶
| 종류 | 설명 |
|---|---|
| 구문(Statement) 커버리지 | 모든 구문 실행 여부 |
| 결정(Decision) 커버리지 | 모든 분기 조건 True/False |
| 조건(Condition) 커버리지 | 각 조건의 True/False |
| MC/DC 커버리지 | 항공/의료 분야 높은 기준 |
시험 포인트¶
- 폭포수 vs 애자일: 요구사항 명확 → 폭포수, 변화 많음 → 애자일
- 스크럼 3가지 역할: PO, 스크럼 마스터, 개발팀
- UML 관계: 합성(검은 마름모) vs 집합(흰 마름모) 구분
- 디자인 패턴 3분류: 생성/구조/행동
- 블랙박스 vs 화이트박스: 내부 구현 알고리즘 지식 여부
- 단위 → 통합 → 시스템 → 인수 테스트 순서 암기