🎫소프트웨어 공학 part02. UP의 반복적 개발

■ SDLC (Software Development Life Cycle)

• 소프트 웨어의 개발 주기

■ 단계별 입력 및 출력물

• 개발 단계의 입력물 : use case, Domain model
• 설계 단계의 출력물 : Interaction diagram Design class diagram

■ 중요모델

• 폭포수 모형 : 전통적 방법
• 프로토타이핑 모형 : 사용자의 피드백을 중시
• 점증적 모형 : 위기 관리 중심

■ Waterfall Model

최초의 체계적으로 설정된 단계
1970년대 항공 방위 소프트웨어 개발 경험으로 습득 됨
각 단계가 다음 단계 시작 전에 끝나야 함
산출물을 중심으로 각 단계별로 독립적인 조직으로 수행 가능.
단순하거나 응용분야를 잘 알고 있는 경우 적합함.

계획 -> 분석 -> 설계 -> 개발

개발 중, 사용자의 의사 반영이 어려워 의도대로 완성되었는지 확인 어려움.
즉, 분석단계의 실수가 시험단계에서 발견됨
처음 단계의 강조는 코딩 및 테스트가 지연되게 됨.
쓸모없는 문서의 생산 가능성이 많음.

Q. 1000라인 코드가 있을 때, 10000라인 길이의 프로그램의 작성하기 위해서는 얼마나 걸릴까?

A. 20M/M -> 프로젝트의 크기(구현된 기능 및 코드)가 커질수록, 요구되는 변경 사항 또한 크게 증가하기 때문.

[해결 방법]

1. 분석을 잘해서 요구사항을 확실하게 도출하거나,
2. 분석,설계 단계에서 요구되는 변경사항을 수용할 수 있도록 대비한다.

■ 프로토타이핑 모형

프로토타입을 선 개발하는 형식으로 하여, 폭포수 모델의 문제를 해결함.
이때 사용자가 참가. But, 사용자가 원하는 기능은 매우 불확실하므로, 재개발이 필요한 경우가 많아 일정을 맞추기가 어렵다.

■ 나선형 모델(Spiral Model)

배경 : 프로토타입 모델은 대규모이거나, 다양한 문제를 포함하는 프로젝트에는 적합하지 않음. (계속 프로토타입을 수정하고 또 수정해줘야 하는 문제 발생)

• 소프트웨어의 기능을 나누어 점증적으로 개발함으로써 실패의 위험을 줄임
• 주요 성공 원인을 바탕으로 우선순위를 정해 개발하고, 여러가지 위험 요소를 찾아내는 것
• 대규모 시스템 개발에 적합하나, 위험 분석 및 관리가 매우 중요하다.

[반복 단계]

1. 계획수립 : 목표, 기능선택, 제약사항을 수립
2. 위험 분석 : 기능 선택에서의 우선순위 및 위험요소를 분석.
3. 개발 : 선택된 기능을 개발.
4. 평가 : 개발된 결과를 평가.

■ UP(Unified Process)

객체 지향 시스템을 구축하는 가장 일반적인 방법론

• 반복적이고 점진적인 개발이 이루어짐
  각 iteration(분석, 설계, 구현, 시험, 통합)과정을 반복하며 점점 완성된 시스템으로 발전 시키는 것.
  이전 iteration의 피드백이 그 다음 iteration의 요구사항 및 분석 설계에 반영된다.
  반복적 개발은 폭포수 모델의 사용자와의 feedback 문제를 해결하기 위해서 사용한다.
  

■ 반복적 개발의 장점

• 프로젝트에서 변경은 필수적인데, 이러한 변경에 대해서 높은 적응성을 가진다.
• (개발 -> 피드백 -> 조정)
  높은 위험 사항들에 대해서 빠른 대처가 가능하다.
  초반 진행상황을 눈으로 볼 수 있어, 빠른 피드백과 적합화로 사용자가 만족하는 시스템이 된다.
  완벽한 분석을 할 필요가 없어, 복잡하고 많은 일을 할 필요가 없다.
  N번째 반복에서 얻은 피드백 N+1번째 반복에 반영되어, 개발 프로세스를 향상시킨다.

■ 반복의 기간

• 4주가 적당하다.
• 반복은 반드시 타음박스화(고정 기간)해야 한다.
• 초기 반복에서 높은 위험사항 및 가치가 높은 사항 발견한다.
• 평가, 피드백, 요구 사항들이 사용자와 지속적 연관된다.
• 초기 반복 시 응집적이고 핵심적인 아키텍쳐를 개발한다.

■ UP의 개발 단계 개발 전체에서의 주요 4단계

Inception(도입)

• 전체적인 비전, 비지니스 케이스, 범위 추정
• 타당성 검토

Elaboration(정련)

• 정제된 비전, 핵심 아키텍처(구조)의 반복적인 구현.
• 높은 위험 항목의 해결, 대부분의 요구사항 및 범위를 식별, 현실적인 추정

Construction(구축)

• 남아있는 낮은 위험 항목과 좀더 쉬운 부분의 반복적 구현, 배치 준비
• 핵심 아키텍처에서 못한 것을 마무리

Transition(전이)

• 베타 테스트 및 배치