[UML Distilled] 2장

2. 개발 공정

UML을 사용하는 방법은 사용하는 공정의 형식에 따라 달라진다.

반복 공정과 폭포수 공정

• 두 공정의 근본적인 차이점은, 하나의 프로젝트를 어떻게 작은 덩어리로 쪼갤 것인가에 있다.

폭포수 방식(Waterfall style)

• 액티비티 기준으로 프로젝트를 나눈다.
• 액티비티는 분석(analysis), 설계(design), 개발(coding), 테스트(testing) 가 있다.
• 각 단계 사이에 어떤 형태의 공식 산출물이 있다.
  • 종종 앞 단계로 돌아가는 경우가 있으니 가능한 최소화되어야 한다.

반복 방식(Iterative style)

• 기능의 부분 집합으로 프로젝트를 나눈다.
• 전체 기능을 등분하여 각 반복마다 요구 사항을 등분한 만큼 개발 사이클(분석, 설계, 개발, 테스트)을 진행한다.
• 반복을 시작하기 전에 일정 형태의 탐색 액티비티가 있다.
  • 요구 사항을 반복 작업으로 나눌 수 있는 정도의 개략적인 관점을 가지게 된다.
• 일반적인 기술로는 시간 구획(time boxing) 을 이용한다.
  • 반복 작업을 정해진 시간 안에 하는 것이다.
  • 개발에 일정한 리듬을 갖도록 한다.
• 반복 개발에 대한 가장 일반적인 고민은 재작업 문제이다.
• 기존 코드를 재작업 하는 것이 종종 효과적이다.
  • 자동 회귀 테스트(Automated regression tests)
    • 무언가를 변경하고 있을 때 발행할 수 있는 모든 결함을 빨리 감지할 수 있도록 도와준다.
    • 단위 테스트 코드의 크기는 완성 코드와 비슷한 크기여야 한다.
  • 리팩토링(Refactoring)
    • 기존의 소프트웨어를 변경하는 체계적인 기술이다.
    • 코드 베이스에 행동을 변화시키지 않는(behavior preserving) 작은 변화를 연속해서 가하여 이루어진다.
  • 연속적 통합(Continuous integration)
    • 고통스러운 통합 사이클을 피하기 위해 팀을 계속해서 동기화하는 것이다.

단계별 출시(staged delivery) : 분석과 개략적인 설계는 폭포수 방식으로 하고 개발과 테스트는 반복 개발로 나누어 진행한다.

예측 계획법과 적응 계획법

• 폭포수 개발 방식이 계속 사용되는 한 가지 이유는 예측 가능성(predicatability) 을 기대하기 때문이다.

예측 계획법(predictive planning)

• 앞으로 어떤 것들을 해야 하는지 알기 위해서 프로젝트 초기에 예측한다.
• 프로젝트의 나머지 부분을 적절한 수준의 정확도로 평가할 수 있는 지점까지 갈 수 있다.
• 예측 기획법을 이용하면 프로젝트는 두 단계로 나누어진다.
  1. 계획을 제안하는 것, 예측하기 힘들다.
  2. 계획이 자리 잡았기 때문에 훨씬 더 예측하기 쉽다.
• 확실한 계획이 자리 잡으면 편차가 적어지기를 기대하는 것이다.
• 프로젝트들이 예측 가능한 가에 대한 논쟁의 중심에는 요구 사항 분석이 있다.
• 프로젝트의 복잡도를 증가시키는 특별한 원인 중의 하나는 시스템의 요구사항을 이해하기가 어렵다는 것이다.
• 프로젝트의 후반부에서 요구 사항이 변경되는 것인 요구 사항 흔들기(requirements churn) 가 문제다.
• 한 가지 해결책은 요구 사항 공정 자체에 더 많은 노력을 기울이는 것이다.
• 고정 비용 / 고정 범위(fixed-price / fixed-scope) 계약을 맺을 수 있다.
  • 어떤 것을 개발할 것이며, 얼마나 비용이 들고 언제 공급할 수 있을지를 정확히 알려준다.

적응 계획법(adaptive planning)

• 예측 계획법을 사용할 수 있을 정도로 요구 사항을 고정시키기는 너무나 힘든 프로젝트가 많다.
• 적응 계획법에서는 예측이라는 것을 환상으로 본다.
• 예측 계획법을 사용한 프로젝트와의 차이점은 ‘프로젝트가 어떻게 되어 가고 있는가.’ 에 대해 사람들이 이야기하는 다양한 방법에서 드러난다.
• 고정 비용 / 가변 범위(fixed-price / variable-scope) 계약을 맺을 수 있다.

---

• 적응 계획법의 접근 방식보다는 예측 계획법의 접근 방식이 더 바람직하다.
• 하지만, 예측 가능성은 엄밀하고 정확하며, 안정된 요구사항에 의존한다.
• 요구 사항을 고정시킬 수 없다면, 예측 계획법은 모래 위에 지은 것이며, 프로젝트가 잘못된 길로 갈 가능성이 크다.

1. 엄밀하고 확실한 요구 사항을 가지고 있으며, 그것이 크게 바뀌지 않을 것이라고 확신하기 전에는 예측적인 계획을 세우지 말라.
2. 엄밀하고 확실하며 안정된 요구 사항을 가질 수 없다면, 적응 계획법을 사용하라.

애자일 프로세스

• 애자일(agile)이란, 정의한 공통의 가치와 원칙을 준수하는 다양한 공정을 대표하는 용어이다.
• 본질적으로 아주 적응적인 방법론이다.
• 프로젝트 성공의 가장 중요한 요인이 구성원들의 능력이며, 구성원들이 얼마나 협업하는지에 달려 있다고 가정한다.
• UML을 스케치용도로 사용한다.

Rational Unified Process

• Rational Unified Process(RUP)를 사용할 때 가장 먼저 해야 할 일은 개발 사례(development case) 를 선택하는 것이다.
  • 개발 사레를 선택하는 것은 RUP에 아주 익숙하고 RUP를 특정한 프로젝트의 필요에 따라서 가공할 수 있는 사람이 미리 해야한다.
• RUP는 근본적으로 반복 공정이다. 모든 RUP 프로젝트는 다음의 네 가지 단계를 따라야 한다.
  • 개념화 단계(Inception)
    • 프로젝트에 대한 초기 평가를 한다.
  • 상세화 단계(Elaboration)
    • 주요 유스 케이스를 도출하고 시스템의 아키텍처를 펼쳐 놓기 위해서 반복적으로 소프트웨어를 개발한다.
    • 이 단계가 끝나면 요구 사항을 잘 이해하고 있어야 하며, 개발의 모체의 역할을 하는 뼈대 시스템(skeleton system)이 동작하고 있어야 한다.
  • 구축 단계(Construction)
    • 계속해서 개발 공정을 진행하고, 릴리즈 하기 충분한 기능을 개발해야 한다.
  • 전이 단계(Transition)
    • 반복적으로 수행하지 않는 다양한 최종 단계의 액티비티를 포함한다.
• 때로 RUP는 Unified Process(UP) 라고 불린다.

공정을 프로젝트에 적용하기

• 모든 프로젝트에 맞는 만능 공정이 있을 것으로 기대해서는 절대 안된다.
• 소프트웨어 개발에 사용하게 되는 방법은 많은 요인에 의해서 결정된다.
  • 개발하고자 하는 시스템의 종류, 사용하려고 하는 기술, 팀의 크기와 구성, 위험 요소의 특성, 실패의 결과, 팀의 일하는 스타일, 회사의 문화 등이 있다.
• 언제나 공정을 특별한 환경에 맞도록 변화시켜야만 한다.
  1. 프로젝트를 살펴보고 어떤 공정들이 맞을 것 같은지 고려한다.
  2. 공정을 어떻게 변화시켜야 프로젝트에 맞을지 고려한다.
     • 사용해 보기 전까지 완전히 파악하기 어려운 공정들이 많다.
     • 이런 경우 어떻게 동작하는지 알게될 때까지 공정을 사용해서 몇 번의 반복을 수행해보는 것이 도움이 된다.
• 시작하게 되면 공정을 믿어라. 그래야 공정을 수행하면서 배울 수 있다.
• 매 반복이 끝날 때, 반복 돌아보기(iteration retrospective) 를 수행하라.
  • 유지할 것(Keep) : 진행이 잘 되어서 계속해서 하려 하는 것들
  • 문제점(Problem) : 잘 되지 않은 부분
  • 시도할 것(Try) : 공정을 개선하기 위해 변화시킬 것들

UML을 공정에 적용하기

요구 사항 분석

• 요구 사항 분석의 액티비티란 소프트웨어의 사용자와 고객들이 시스템이 어떤 것들을 해 주기를 원하는지 파악하기 위해서 노력하는 것이다.
  • 유스 케이스 : 사람들이 시스템과 어떻게 상호 작용을 하는지 보여준다.
  • 개념적인 관점에서 그려진 클래스 다이어그램 : 도메인의 정확한 어휘를 구성하는 좋은 방법이 될 수 있다.
  • 액티비티 다이어그램 : 소프트웨어와 사람의 행동이 어떻게 상호 작용 하는지 보여준다. 복잡한 유스 케이스가 어떻게 동작하는지를 자세히 보여줄 수 있다.
  • 상태 다이어그램 : 어떤 개념이 다양한 상태와 그 상태를 변경하는 이벤트로 구성되어 흥미로운 생명 주기를 가지고 있을 때 유용하다.
• 가장 중요한 것은 사용자와 고객과 대화하는 것이다.
• 기술과 거리가 먼 사람들을 이해시키기 위해 표기법을 최소한으로 유지하는 것이 중요하다.

설계

• 다이어그램에 좀 더 기술적인 표현을 해도 좋다.
  • 소프트웨어 관점에서의 클래스 다이어그램 : 소프트웨어 내의 클래스와 이 클래스들이 서로 어떻게 연관되는지를 보여 준다.
  • 공통 시나리오에 대한 시퀀스 다이어그램 : CRC 카드나 시퀀스 다이어그램을 사용하여 소프트웨어에서 무엇이 일어나는지 알아낼 수 있다.
  • 소프트웨어의 구조를 큰 단위로 나타내는 패키지 다이어그램
  • 복잡한 생성 이력을 가지는클래스에 대한 상태 다이어그램
  • 소프트웨어의 물리적인 레이아웃을 보여주는 배치 다이어그램
• 폭포수 기법에서는 UML을 청사진으로 사용한다고 가정한다.
• 반복 스타일에서는 UML이 청사진이나 스케치로 사용될 수 있다.
• 청사진 설계는 반복의 초기에 이루어지는 것이 보통이지만, 해당 반복에서 개발하고자 하는 기능의 범위에 따라서 분리해서 만들어질 수도 있다.
• 스케치로 사용하는 것은 반복의 초기 며칠을 할애하여 해당 반복에 대한 초안을 설계한다.
  • 대안을 찾는 가장 좋은 방법이다.

문서화

• 소프트웨어를 개발한 후에 한 일을 문서화하기 위해 UML을 사용한다.
• 전체 시스템에 대해 자세한 다이어그램을 만들어야 한다고 생각하지 않는다.

조심스럽게 선택해서 잘 기록한 메모는 전통적인 복잡한 설계 문서를 쉽게 대체할 수 있다. 후자는 일부분 외에 거의 도움이 되지 않는다. 이 일부분을 강조하고 나머지는 잊어버려라.(워드 커닝햄, Cunningham)

• 패키지 다이어그램은 시스템에 대한 좋은 논리적인 로드 맵이 된다.
• 물리적인 모습을 개략적으로 보여주는 배치 다이어그램도 이 단계에서 유용할 수 있다.
• 클래스 다이어그램은 시스템의 가장 중요한 상호 작용을 나타내는 몇 개의 교류 다이어그램의 지원을 받아야 한다.
• 클래스가 복잡한 생명 주기를 보인다면, 상태 기계 다이어그램을 그린다.
• 복잡한 알고리즘이 있다면, 액티비티 다이어그램을 사용하는 것을 고려한다.

오래된 코드를 이해하기

• 코드를 탐색할 때 중요한 부분을 공략하기 위해서 사용하라.
• 복잡한 메소드를 처리하기 위해서 많은 객체들이 어떻게 협력하는지를 보여 주는 시퀀스 다이어그램을 만드는 것이 좋다.