OOAD, Iterative & Agile, Case

이 포스트는 OOAD와 Iterative & Agile, Case 에 대한 요약이다. 그리고 추가적으로 Inception에 대한 설명도 들어가 있다.

1. OOAD

OOAD = Object-Oriented Analysis and Design

• Object-Oriented Analysis(OOA) - 객체 지향 분석

  • 문제 도메인 개념(객체를 식별함), 시스템이 무엇을 해야하는지에 초점
  • 사용자 요구사항을 이해하고, 이를 객체 개념으로 분석하는 단계

• Object-Oriented Design (OOD) - 객체 지향 설계

  • 소프트웨어 객체 정의 및 협력 관계 설정
  • 분석단계에서 도출된 객체 모델을 바탕으로, 어떻게 구현할지를 설계하는 단계
  • 해결 영역 중심으로, 시스템이 어떻게 동작해야 하는지에 초점

Analysis(investigation of the problem) -> Design(logical solution) -> Construction (code) 순으로 진행

OOAD 예제 : Dice Game (주사위 게임)

1. Use Case 정의
   • UC1: 주사위 게임 실행
2. Domain Model 작성
   • 주요 도메인 객체, 속성, 연관관계 표현
3. Interaction Diagram 작성
   • 시나리오 기반 메시지 흐름
4. Design Class Diagram
   • 구현 대상 클래스 설계

개발 단계

• 요구사항 → 분석 클래스 → 설계 클래스 → 소스 코드 → 테스트
• UML 시점:
  1. Conceptual perspective: 실제 세계 모델링
  2. Specification(software) perspective: 추상적 소프트웨어 구성
  3. Implementation perspective: 실제 구현과 연결 (Java 등)
     • 타입과 정보 등 고도의 문법을 지정

현실에서 자주 사용하는 것은 1,3 임.

---

2. Iterative, Agile Process

소프트웨어 개발 프로세스

• 소프트웨어를 만들기 위해 수행해야 할 여러 활동과 그 활동 간의 관계를 정의한 절차
• 각 활동이 어떤 순서로, 어떤 방식으로 연결되어 있는지를 정의함.

Iterative

UP (Unified Process)

• 객체지향 시스템을 만들기 위한 반복적(iterative) 개발 방식의 대표적인 방법
• 소프트웨어를 한번에 완성하지 않고, 여러번에 걸쳐 조금씩 개선하며 완성해 나가는 방식
• 특징
  • Iterative : 여러 사이클을 돌며 점진적으로 개발
  • Architecture-centric : 소프트웨어 구조 (아키텍처)를 중심에 두고 설계 진행
  • Use-case driven : 사용자 요구사항을 Use Case로 정리하여 시스템을 개발

반복적, 진화적 개발의 개요

• Iterative Development : 프로젝트를 여러 개의 반복 단계로 나누어 개발하는 방법

• Build -> Feedback -> Adapt 를 Cycle로 변경 수용

• 장점
  • 위험을 조기에 제거
  • 고객의 피드백을 기반하여 개발
  • 점진적 개선과 품질을 확보
  • 과도한 문서 작업을 지양 (Agile Modeling)
  • 사용성, 목적성이 향상
• Iteration 기간
  • 2~6주 권장 (짧아야 함.)
  • Timeboxing : 한 번 정해진 기한을 변경하지 않고 고정

기한이 지나면 미완성된 작업도 멈춘다

Waterfall Life-Cycle의 문제

• 요구사항은 항상 바뀌기 때문에 초기에 고정하는 것은 비현실적 ( 초기에 고정 : Waterfall Life-Cycle)
• 사용되지 않는 기능이 다수 포함
  • 약 45%가 만들어놓고 쓰지 않는다는 기록이 있음.

Risk-Driven, Client-Driven

1. UP는 두 가지 계획 방식을 조합하기를 권장함.
   • Risk-driven : 위험 중심
   • Client-driven : 고객 중심

• 이를 통해 먼저 위험 요소를 찾아 해결할 수 있고, 고객이 가장 원하는 기능을 먼저 보여줄 수 있음.

1. Risk-driven 개발 = Architecture 중심 개발
   • 구조가 흔들리면 전체 프로젝트에 리스크가 크기 때문
   • 시스템 구조(아키텍처)를 먼저 개발하고 검증
   • 보통은 Iteration 3 쯤에 아키텍처 설정

Before iteration-1

잘못된 오해

프로그래밍 전에 분석과 설계는 의미 없다.

처음부터 완벽하게 분석하는 것이 능력이다.

분석과 설계는 중요하지만, 전체를 다 하려고 하지 말고 중요한 것만 먼저 하자

• Iteration-1 전에 **전체 요구사항을 완벽히 분석하지는 않는다.
• 2일짜리 워크숍으로 빠르게 분석 및 계획을 수립

예시)

1. 1단계 : 첫 0.5일 (반나절)
   • High-level requirements analysis (고수준 요구사항 분석) : 전체 Use-case 중 10%만 선택
   • 선택 기준
     • 아키텍쳐에 중요한지의 대한 여부
     • 비즈니스 가치가 높은지에 대한 여부
     • 위험도가 높은지에 대한 여부
2. 2단계 : 나머지 1.5일
   • 선택한 10% 케이스에 대한 기능적/비기능적 요구사항을 집중적으로 분석
   • 나머지 90%는 여전히 High-level수준으로 남겨둠.

Agile Modeling

소프트웨어 시스템을 빠르게 모델링하고 문서화하는 실용적인 방법론

이해와 커뮤니케이션 중심의 가볍고 유연한 모델링 방식

원칙

• Agile Method를 따른다고 해서 **모델링을 아예 안하는 것은 아니다. **(모델링은 여전히 중요한 활동)
• 모델링의 목적 : 코드로 옮기기 전에 서로 이해하고 공유하기 위한 것 (discover, understand, share)
• 모든 모델은 부정확함. (코드와 설계는 결국 모델과 다르게 진화함.)
• OO설계 모델링은 개발자가 직접 해야함.

Unified Process (UP)의 구성

1. Inception Phase (개념 수립 단계)

프로젝트의 타당성 검토와 범위 정의

주요 활동

• 핵심 요구사항 식별 (Use Case 수준)
• 이해 관계 파악
• 초기 비즈니스 사례 수집, 초기 리스크 분석
• 개략적인 프로젝트 일정과 예산 산정

1. Elaboration Phase (정제 단계)

시스템 아키텍쳐 정의 및 리스크 제거

주요 활동

• 상세 Use Case 모델링
• 아키텍쳐 결정 및 프로토타입 개발
• 주요 기술 리스크 제거
• Iteration 계획을 수립

1. Construction Phase (구현 단계)

기능 구현과 테스트

• 전체 시스템의 실제 코드 작성 (아직 남은 위험도가 작은 것과 구현하기 쉬운 요소들까지 해결)
• 반복적으로 빌드, 통합, 테스트
• 사용 가능한 소프트웨어 버전 생성 ( deployment를 위한 준비 )

1. Transition Phase (전이 단계)

시스템을 실제 사용자에게 배포하고 안정화

주요 활동

• 사용자 교육 및 배포
• 버그 수정, 성능 개선, 피드백 수집 및 반영

UP Terminology

• Disciplines: 요구분석, 설계, 구현, 테스트 등 활동 묶음
• Artifacts: 산출물(코드, 다이어그램, 문서 등)

이론적인 요구사항의 분석의 기초의 inception phase

1. Iteration 1

• 객체 지향 분석/설계의 기초 개념 도입
• 각 기능을 어떤 객체가 담당할지 역할을 할당

1. Iteration 2

• 본격적인 객체 설계
• 디자인 패턴을 소개하고 적용 방법을 설명

1. Iteration 3

• 시스템 전반의 아키텍처 분석
• 프레임워크를 설계하는 내용을 포함

• UP에 대해 오해할만한 사항

1. 개발 전에 대부분의 요구사항과 설계를 다 정의하려고 한다.
2. UML 모델링에 너무 많은 시간을 들인다.
3. UP 단계를 Waterfall 모델처럼 본다.
4. elaboration 단계는 모델을 완벽하게 정의하는 단계라고 생각한다.

• Elaboration 단계는 실험과 리스크 제거, 아키텍처 확정이 핵심

1. Iteration은 3개월 정도가 적당하다고 생각한다.
2. UP은 문서 많이 만들고 절차가 복잡하다고 생각한다.

• UP은 가볍고 유연하게 운영할 수 있는 프레임워크로 필요한 작업만 하기에 문서도 최소한으로 충분

1. 프로젝트 전체를 처음부터 끝까지 상세하게 계획하려 한다.

• 매 Iteration마다 계획하고 점진적으로 정하는 방식이 UP의 본질

---

Case

책에서 다루는 범위

초점 : 애플리케이션 로직 계층 (Core Application Logic)

미포함 : UI, DB, 외부 시스템 연동

초점적인 부분에 대해 공부하지만, 미포함 적인 부분들도 다 Case를 나눠야 함.

기술 변화가 심한 계층보다는 OO 설계 역략에 집중

---

부록) Larmen Chatper 4~5 요약

Inception

프로젝트 초기에 요구하는 짧은 질문들

• 비전과 사업 타당성, (실행 가능 여부)
• 직접 개발 or 구매?
• 대략적인 비용
• 계속 진행할 것인지 멈출 것인지

Inception 단계는 짧아야한다.

• 1주 이내이며, 반복은 없어야한다.
• 대부분의 요구사항 분석은 elaboration phase에서 수행.

Inception 단계의 산출물 (Artifacts)

Artifact	설명
Vision & Business Case	목표, 제약사항, 요약
Use-Case Model	주요 유스케이스 이름 정의, 일부만 상세화 (약 10%)
Supplementary Spec	비기능 요구사항의 대략적인 윤곽
Glossary	핵심 도메인 용어 및 데이터 사전
Risk List & Plan	비즈니스, 기술, 일정 리스크 및 대응 방안
Prototypes / PoC	기술 검증, 비전 명확화
Iteration Plan	Elaboration 단계의 첫 반복 계획
Phase & Dev Plan	자원, 기간, 인력 등 계획 (정밀도 낮음)
Development Case	프로젝트 맞춤 UP 정의 및 아티팩트 목록

UML 사용 여부

Inception 단계의 목적

• common vision의 설계
• feasible(타당성) 판단
• elaboration 단계의 진행 여부 결정

=> Inception 단계에서는 UML 다이어그램을 거의 사용하지 않는다.

요약

Inception 단계는 필수는 아니지만, 실수를 줄이기 위한 안전장치

특히 리스크가 크거나, 요구사항이 복잡하거나, 이해 관계자가 많은 경우에는 짧게라도 꼭 수행하는 것이 좋다.

Evolutionary Requirements

UP의 요구사항

• 시스템이 만족해야 할 조건 / 기능

• 점진적이고 반복적인 분석 과정

요구사항 카테고리

FURPS+ 모델

분류	설명
F (Functional)	기능, 보안 등
U (Usability)	사용성, 도움말, 문서
R (Reliability)	신뢰도, 오류율, 복구 가능성
P (Performance)	응답시간, 정확성, 자원 사용
S (Supportability)	유지보수성, 국제화, 설정 가능성
+ (Constraints)	구현, 인터페이스, 운영, 포장, 법적 제약 등

URPS는 보통 품질 요건(Quality Requirements) 으로 분류됨

• **성능, 안전성, 보안성, 사용성, 유지보수성 ** 등 품질에 관한 조건

요구사항 조직화 (Artifacts)

Artifact	설명
Use-Case Model	기능적 요구사항 중심, 시스템 사용 시나리오
Supplementary Spec	비기능 요구사항 중심, 유스케이스에 없는 기능 포함
Glossary	데이터 관련 요구사항, 유효값, 규칙 포함
Vision	프로젝트 핵심 아이디어와 전체 개요 요약
Business Rules	도메인/비즈니스 상의 법규, 정책 등 반영

##

• Inception은 비전, 리스크, 타당성 평가 중심으로 짧게 수행
• Elaboration에서 대부분의 요구사항이 도출되고 분석됨
• 요구사항은 반복적/점진적으로 도출 및 검증되어야 하며,
• FURPS+로 다양한 요구사항을 구조화하고 아티팩트를 통해 명확하게 표현