[Software Engineering] 시스템 개발 생명주기(SDLC)와 주요 방법론

 

 

Systems Development Life Cycle (SDLC)

SDLC는 모든 시스템 개발 프로젝트가 따르는 기본 프로세스이며 , 방법론은 SDLC를 구현하기 위한 정형화된 접근 방식입니다. SDLC는 일반적으로 4단계로 구성된다.

 

 

1. Planning (계획)

• 주요 질문: 이 시스템을 왜 구축해야 하는가? 어떤 가치를 제공하는가? 구축에 얼마나 걸릴 것인가? (실제로 개발할지 결정하는 타당성 검증)
• 주요 활동: 프로젝트 착수 (시스템 요청 개발/수신, feasibility analysis - 타당성 분석 수행), 프로젝트 관리 (작업 계획 개발, 인력 배치, 모니터링 및 통제).

2. Analysis (분석)

• 주요 질문: 누가 사용할 것인가? 시스템이 우리를 위해 무엇을 해야 하는가? 언제, 어디서 사용될 것인가?
• 주요 활동: 분석 전략 개발(현재 시스템 (as-is system) 모델링 및 문제점 파악, 새로운 시스템 (to-be system) 개념 구상), 요구 사항 수집, 비즈니스 분석 모델 생성, 시스템 제안서 개발.

3. Design (설계)

• 주요 질문: 어떻게 구축해야 하는가?
• 주요 활동: 설계 전략 개발 (방향, 범위, 기술 스택), 아키텍처 설계 (하드웨어, 소프트웨어, 네트워크, 인터페이스), 데이터베이스 및 파일 명세 개발, program design (작성할 프로그램과 각 프로그램이 수행할 작업 명세). 결과물은 System Design Specification.

4. Implementation (구현)

• 주요 활동: 시스템 구축 (코드 작성 및 테스트), 시스템 설치 (배포 계획, 시스템 설치, 데이터 마이그레이션), 사용자 교육, 시스템 지원 (유지보수).

 

 

 

---

 

 

SDLC 방법론

위에서 본 4가지 phases를 어떻게 배치하고 실행되냐에 기준으로 각각의 방법론이 등장했다. SDLC는 여러 가지 방법론으로 구현될 수 있으며, 크게 구조적 (Structured), RAD (Rapid Application Development), 애자일 (Agile), 객체 지향 (Object-Oriented) 등으로 분류된다.

 

 

"무엇을 중심으로 구현할 것인가?"에 따라서 다음과 같이 구분한다.

• Process oriented (처리 과정 중시)
• Data centered (데이터 중심적 구현)
• Object-oriented (객체로 설계 & 관리)

 

SDLC 방법론에 따라서는 크게 다음과 같이 구분된다.

• Structured
• Rapid Application Development
• Agile development

 

 

 

 

Structured Methodologies

구조적 방법론은 일반적으로 계획, 분석, 설계, 구현 단계를 순차적으로 실행하거나 병렬로 실행하는 데 중점을 둔다. 데이터 중심 또는 프로세스 중심 방법론과 같은 예가 있다.

 

 

(1) Waterfall

• 흐름: Planning → Analysis → Design → Implementation 순서로 단계를 진행한다. 가장 초기에 등장한 방법이며, 순차적이고 앞단계가 완벽하게 끝나야 뒷단계로 이동하는 특징이 있다. Data-centered, process-centered 방법론이다. 

 

 

• 장점:
  • 시스템 요구 사항을 개발 초기 단계에 식별할 수 있다.
  • 요구 사항 변경을 최소화할 수 있다.
• 단점:
  • 설계가 개발 초기 단계에서 완료되어야 한다.
  • 시스템 제안부터 소프트웨어 전달까지 긴 시간이 소요된다.

 

(2) Parallel

• 흐름: Analysis 단계 후 시스템의 독립적인 모듈 및 컴포넌트를 여러 팀이 병렬로 설계하고 구현하며, 최종적으로 통합(Integration)하여 시스템을 완성한다. 독립적인 모듈과 컴포넌트 개발로 더 빠르게 전달할 수 있다.

 

• 장점:
  • 독립적인 모듈 개발로 더 빠른 전달이 가능하다.
  • Analysis와 delivery 사이의 지연을 줄여 비즈니스 요구 사항 변경 가능성을 낮춘다.
  • 자원을 효율적으로 활용하며, 위험을 분산하고 빠른 피드백이 가능하다.
• 단점:
  • 주제가 완전히 독립적이지 않을 경우, 통합(integration), 커뮤니케이션, 종속성 문제가 발생할 수 있다.
  • 독립된 모듈로 분리가 안될 수 있다.

 

 

---

 

 

RAD: Rapid Application Development

RAD는 독립적인 모듈과 컴포넌트를 신속하게 개발 & 통합하는 데 중점을 둔다.

 

(1) Phased Development

• 흐름: Analysis, Design, Implementation 단계가 순차적으로, 그리고 우선순위를 정의해서 중요도가 가장 높은 것부터 가장 낮은 것의 순서로 반복된다. 각 반복마다 시스템의 새로운 버전(System version 1, System version 2 등)을 사용자에게 제공한다.Phased Development는 완성된 부분 시스템을 단계별로 출시하며, 각 단계는 실제 운영 가능한 버전이다. 반면 Prototyping은 완전한 시스템이 아닌, 사용자 피드백을 위한 실험적 버전이다.

 

 

 

• 장점:
  • 사용자가 시스템에 초기에 접근하여 새로운 요구 사항을 발견할 수 있다.
• 단점:
  • 의도적으로 불완전한 시스템으로 작업하게 되어 첫 번째 요구 사항 세트의 중요성이 높아잔다.
  • 사용자의 기대치 관리가 중요하다. (사용자 피드백 관리 중요)

 

 

(2) Prototyping

• 흐름: Planning→ Analysis → Design → Implementation 단계를 빠르게 반복하여 시스템 프로토타입을 빠르게 만든다. 이때 System prototype은 완성된 상태가 아니다.

 

• 장점:
  • 시스템(프로토타입)을 더 빠르게 출시할 수 있다.
  • 사용자 피드백을 빠르게 얻을 수 있다.
• 단점:
  • 불완전한 분석 및 설계로 인해 재작업(rework) 비용이 발생할 수 있다.
  • 시스템 복잡성이 증가할 수 있다.

 

(3) Throw-away prototyping

• 흐름: Planning → Analysis 단계 후, Design 단계 이전에 Design prototype을 만들어 Analysis을 정제하는 데 사용하고, 이 프로토타입은 최종 시스템으로 발전시키지 않고 폐기한다. 이후 정식 설계 구현을 진행한다. 따라서 Design prototype은 실험용으로 User 피드백을 받기위한 용도이며 이후 수정을 통해 complele한 Design이 나온다.

 

 

• 장점:
  • 심사숙고된 Analysis 및 Design 단계의 이점을 누릴 수 있다.
  • 프로토타이핑을 사용하여 정제하는 이점을 활용할 수 있다.
• 단점:
  • 전달(Delivery)까지 시간이 더 오래 걸릴 수 있다.

 

 

---

 

Agile Development

애자일 방법론은 프로그래머 중심적 방법론이다.

 

• 가치:
  • 개인과 상호작용 > 프로세스와 도구
  • 작동하는 소프트웨어 > 포괄적인 문서
  • 고객 협력 > 계약 협상
  • 변화에 대한 대응 > 계획 준수

 

 

• 장점:
  • 프로그래머 중심적인 개발론
• 단점:
  • 개발 팀의 비현실적인 공동 배치(co-location)가 필요하다.
  • "프로그래머가 통제 불능이 되는" 환경이 될 수 있다.
  • 문서화가 부족할 수 있다.
  • 대규모 mission-critical 시스템에는 부적합하다.

 

 

---

 

 

Object-Oriented System Analysis & Design (OOSAD)

OOSAD(Object-Oriented System Analysis & Design)는 data와 process의 균형을 맞추려고 시도하며, 종종 RAD 또는 애자일 방법론과 연관된다. UML(Unified Modeling Language)과 Unified Process를 활용한다.

 

• 특징:
  • 유스케이스 중심 (Use-case driven): 유스케이스는 시스템의 동작(behavior)을 정의하는 주요 모델링 도구이다. 각 유스케이스는 하나의 비즈니스 프로세스에 초점을 맞춰 단순하고 효율적이다.
     
  • 아키텍처 중심 (Architecture Centric): 시스템의 세 가지 아키텍처 관점(views)을 사용한다:
    
    • 기능적 (Functional) 관점 (외부): 사용자의 관점에서 바라본다.
    • 정적/구조적 (Structural) 관점: 속성, 메서드, 클래스 및 관계에 초점을 맞춘다.
    • 동적/행동적 (Behavioral) 관점: 클래스 간의 메시지와 그로 인한 동작 측면에서 바라본다.
  • 반복적 및 점진적 (Iterative & Incremental): 지속적인 테스트와 정제를 거치며, 분석가가 시간이 지남에 따라 시스템을 더 잘 이해하게 된다.
• 이점: 복잡한 시스템을 작고 관리하기 쉬운 모듈로 나누고, 모듈별로 개별적으로 작업하며, 사용자가 시스템을 보는 방식대로 더 현실적으로 시스템을 볼 수 있게 해준다.

 

 

Unified Process

Unified Process는 OOSAD를 지원하며, 반복적이고 점진적인 특성을 가진다. (OOSAD의 구체화된 방법론)

4개의 주요 단계를 가진다:

1. Inception (착수):
   
   • 타당성(Feasibility) 분석을 수행한다.
   • 주요 활동은 비즈니스 모델링 및 요구 사항 수집에 중점을 둔다.
2. Elaboration (상세):
   
   • 분석 및 설계에 중점둔다.
   • 다른 워크플로우도 포함될 수 있다.
3. Construction(구축):
   • 프로그래밍(구현)에 중점을 둔다.
4. Transition):
   
   • 테스트 및 배포에 중점을 둔다.

 

 

---

 

 

결론

어떤 방법론이든 완벽한 것은 없으며 (No silver-bullet), 개발 상황에 가장 적합한 것을 취사선택해야 한다.

 

 

 

 

 

 

출처: 경북대학교 손정주 교수님, “소프트웨어설계” 강의 자료