주제

반복의 필요성

일반적으로 프로젝트는 순서의 각 규칙을 한 번씩만 준수하도록 구성되며 이를 통해 다음과 같은 워터폴 라이프사이클이 형성됩니다.

이 다이어그램은 비즈니스 모델링에서 전개까지의 하나의 반복을 보여줍니다.

이 경우 제품을 처음 빌드하여 테스트가 시작될 때 통합 '파일업'이 구현에서 늦어지는 경우가 종종 있습니다. 분석, 설계 및 구현시 계속 잠재되어 있는 문제점이 실제로 발생하여 오랜 시간이 소요되는 버그 수정 주기가 시작되면 프로젝트가 정지됩니다.

위험이 적은 보다 유연한 처리 방법은 다양한 개발 규칙을 여러 번 준수함으로써 요구사항에 대해 보다 잘 이해하고 강력한 구조를 설계하고 개발 조직을 구성하고 점진적으로 완료되는 일련의 구현을 전달하는 것입니다. 이를 반복 라이프사이클이라고 합니다. 프로세스 규칙 순서를 통한 각 전달을 반복이라고 합니다.

이 다이어그램은 각각 비즈니스 모델링에서 전개로 이동하는 세 개의 연속 반복을 보여줍니다.

따라서 개발 관점에서 볼 때 소프트웨어 라이프사이클은 소프트웨어를 계속 개발하는 일련의 반복입니다. 각 반복은 실행 가능 제품의 릴리즈로 종결됩니다. 이 제품은 완전한 비전의 서브세트가 될 수 있지만 특정 엔지니어링 및 사용자 관점에서 유용합니다. 각 릴리즈에는 지원 결과물(릴리즈 설명, 사용자 문서, 계획 등)과 갱신된 시스템 모델이 제공됩니다.

이러한 반복 방법을 수행하면 기본적으로 앞에서 설명한 결과물 세트가 생성됩니다. 이 결과물은 다음 다이어그램과 같이 오랜 시간을 걸쳐 형성됩니다.

개발 단계를 통한 정보 세트 전개

반복의 개념 페이지 맨 위

반복에는 개발 활동이 포함됩니다. 개발 활동을 수행하면 이 릴리즈를 사용하기 위해 필요한 기타 주변 요소와 함께 제품의 안정적인 실행 가능 버전인 제품 릴리즈가 생성됩니다. 따라서 개발 반복은 어떤 의미에서 모든 규칙(요구사항, 분석 및 설계, 구현과 테스트)을 통한 하나의 완전한 전달입니다. 이는 본질적으로 소규모 워터폴 프로젝트와 유사합니다. 평가 기준은 각 반복을 계획할 때 설정됩니다. 릴리즈는 보여줄 수 있는 성능을 계획합니다. 반복 지속 기간은 프로젝트의 크기 및 성질에 따라 다르지만 반복에 대한 통합 빌드 계획에서 지정하는 대로 반복에 여러 빌드가 구성될 수 있습니다. 이는 RUP(Rational Unified Process)에서 권장하는 지속적인 통합 방법의 결과로서 단위 테스트 컴포넌트를 사용할 수 있게되면 해당 컴포넌트가 통합되어 빌드가 생성되고 통합 테스트를 받게 됩니다. 이와 같은 방식으로 반복을 계속 수행하면서 통합 소프트웨어의 성능이 개선되어 통합 계획시 설정한 목표를 달성합니다. 각 빌드가 최소 통합을 나타내는지 여부에 대해 의문을 가질 수 있지만 필요한 계획과 수행한 평가의 형식에는 차이가 있습니다. 프로젝트에 따라 매일 빌드를 구성하는 것이 적합하고 편리할 수도 있지만 RUP가 정의하는 반복을 나타내지는 않습니다(소규모의 단일 사용자 프로젝트 제외). 소규모 복수 사용자 프로젝트(예: 10,000개의 코드 행을 빌드하는 다섯 명의 사용자 포함)의 경우도 일주일 미만의 반복 지속 기간을 달성하는 것은 매우 어렵습니다.

릴리즈

릴리즈는 내부 또는 외부일 수 있습니다. 내부 릴리즈는 이정표의 일부로서 또는 사용자 또는 고객에게 대한 시연용으로 개발 조직에 의해서만 사용됩니다. 외부 릴리즈(또는 전달)는 일반 사용자에게 전달됩니다. 릴리즈는 완벽한 제품일 필요는 없으나, 엔지니어링 관점에서만 유용성을 측정할 경우 방법에 따라 한 단계일 수 있습니다. 릴리즈는 개발 팀이 "90% 완료, 90% 남음"과 같은 현상을 방지하기 위해 일정한 간격으로 마감하는 강제 실행 기능 역할을 수행합니다.

반복과 릴리스를 통해 팀의 다양한 전문 기능(설계자, 테스터, 작성자 등)을 오랜 시간 동안 보다 효율적으로 사용할 수 있습니다. 정기적인 릴리즈를 통해 통합 및 테스트 사안을 분류하여 개발 주기에 분배할 수 있습니다. 이러한 사안으로 인해 종종 대규모 프로젝트가 실패하기도 하는데, 이는 모든 문제점이 주기 마지막 단계에서 발생하는 대규모 단일 통합 단계와 단일 문제점으로 전체 팀이 중지되는 경우 즉시 발견되기 때문입니다.

각 반복시 결과물이 갱신됩니다. 이는 "갱신되는" 소프트웨어와 유사합니다. 결과물을 하나씩 개발하는 대신 속도는 다르더라도 파이프라인 방식으로 주기에서 개발할 수 있습니다.

보조 이정표

각 반복은 해당 특정 반복의 목표 성공 기준에 따라 반복 결과를 평가하는 보조 이정표로 종결됩니다.

반복 및 단계페이지 맨 위

단계에서 각 반복을 수행하면 실행 가능한 시스템 릴리즈가 생성됩니다.

RUP의 각 단계는 반복으로 보다 세분화하여 분류될 수 있습니다. 반복은 실행 가능 제품, 개발 중인 최종 제품 서브세트의 릴리즈(내부 또는 외부)를 생성하는 전체 개발 루프입니다. 최종 시스템이 되기까지 반복에서 반복으로 단계적으로 전개됩니다.

반복 패턴: 증분 라이프사이클 페이지 맨 위

"증분 전략은 사용자 요구를 결정하고 시스템 요구사항을 정의한 후 일련의 빌드로 나머지 개발을 수행합니다. 시스템이 완료될 때까지 첫 번째 빌드는 계획된 성능의 일부를 통합하고 다음 빌드는 성능을 더 추가합니다."[DOD94]

다음 반복에는 해당 특성이 있습니다.

  • 범위 및 비전을 설정하고 비즈니스 케이스를 정의하는 간단한 초기 반복
  • 요구사항을 정의하고 구조를 설정하는 단일 구현 반복
  • 유스 케이스를 구현하고 구조를 확장하는 여러 구축 반복
  • 사용자 커뮤니티로 제품을 이주하는 여러 전이 반복

첨부 텍스트에서 설명하는 다이어그램

이 전략은 다음과 같은 경우에 적절합니다.

  • 문제점 도메인을 잘 알고 있습니다.
  • 위험을 잘 이해하고 있습니다.
  • 프로젝트 팀의 경험이 풍부합니다.

반복 패턴: 전개 라이프사이클 페이지 맨 위

"전개 전략은 사용자 요구를 완전히 이해할 수 없고 모든 요구사항을 완전히 정의할 수 없으며 각 연속 빌드에서 정제된다는 것을 알고 있다는 점에서 증분 전략과 다릅니다." [DOD94]

다음 반복에는 해당 특성이 있습니다.

  • 범위 및 비전을 설정하고 비즈니스 케이스를 정의하는 간단한 초기 반복
  • 각 반복시 요구사항이 정제되는 다양한 구현 반복
  • 유스 케이스를 구현하고 구조를 확장하는 단일 구축 반복
  • 사용자 커뮤니티로 제품을 이주하는 여러 전이 반복

첨부 텍스트에 설명된 다이어그램

이 전략은 다음과 같은 경우에 적절합니다.

  • 새로운 문재점 도메인이거나 잘 알지 못합니다.
  • 팀의 경험이 풍부하지 않습니다.

반복 패턴: 증분 전달 라이프사이클 페이지 맨 위

일부 작성자는 고객에게 증분 기능을 단계별로 전달합니다[GIL88]. 이는 시장 출시까지의 시간은 부족하지만 특정 중요 기능을 일찍 전달함으로써 중요한 비즈니스 수익을 얻을 수 있는 경우에 필요합니다.

단계 반복 방법에서 전이 단계가 일찍 시작되고 가장 많이 반복됩니다. 이 전략에는 매우 안정적인 구조가 필요하며 "신규" 시스템의 경우 초기 개발 단계에서 이러한 구조를 달성하기는 어렵습니다.

다음 반복에는 해당 특성이 있습니다.

  • 범위 및 비전을 설정하고 비즈니스 케이스를 정의하는 간단한 초기 반복
  • 안정적인 구조를 기반으로 하는 단일 구현 반복
  • 유스 케이스를 구현하고 구조를 확장하는 단일 구축 반복
  • 사용자 커뮤니티로 제품을 이주하는 여러 전이 반복

첨부 텍스트에 설명된 다이어그램

이 전략은 다음과 같은 경우에 적절합니다.

  • 다음과 같이 문제점 도메인을 잘 알고 있습니다.
    • 구조 및 요구사항을 개발 주기 초기에서 안정시킬 수 있습니다.
    • 잘 알려져 있는 문제점입니다.
  • 팀의 경험이 풍부합니다.
  • 기능의 증분 릴리즈는 고객에게 높은 가치가 있습니다.

반복 패턴: "대규모 설계" 라이프사이클 페이지 맨 위

종래의 워터폴 방법은 구축 단계에서 한 번만 반복하는 퇴보 케이스로 볼 수 있습니다. [DOD94]에서는 이 방법을 "대규모 설계"라고 합니다. 실제로는 전이 단계에서 추가 반복을 피하기 어렵습니다.

다음 반복에는 해당 특성이 있습니다.

  • 범위 및 비전을 설정하고 비즈니스 케이스를 정의하는 간단한 초기 반복
  • 유스 케이스를 구현하고 구조를 확장하는 매우 긴 단일 구축 반복
  • 사용자 커뮤니티로 제품을 이주하는 여러 전이 반복

첨부 텍스트에 설명된 다이어그램

이 전략은 다음과 같은 경우에 적절합니다.

  • 정의된 기능이 다소 증가하면 매우 안정적인 제품이 추가됩니다.
  • 새 기능은 잘 정의되어 쉽게 이해할 수 있습니다.
  • 문제점 도메인 및 기존 제품에 대해 팀의 경험이 풍부합니다.

반복 패턴: 혼성 전략 페이지 맨 위

실제로는 하나의 전략을 준수하는 프로젝트는 거의 없습니다. 일반적으로는 혼성(시작시 일부 전개, 일부 증분 빌드 및 여러 전달)을 수행합니다. 단계 반복 모델의 장점 중 하나는 다음과 같이 특정 단계에서의 반복 길이 및 수를 늘리는 것만으로 혼성 방법을 수용할 수 있다는 것입니다.

  • 많은 탐색을 수행하는 복잡하거나 친숙하지 않은 문제점 도메인의 경우, 구현 단계의 반복 횟수 및 해당 길이를 늘리십시오.
  • 설계를 코드로 변환하기가 어려운 모든 복잡한 개발 문제점의 경우, 구축 단계의 반복 횟수 및 해당 길이를 늘리십시오.
  • 일련의 증분 릴리즈에서 소프트웨어를 전달하려면 전이 단계의 반복 횟수 및 해당 길이를 늘리십시오.


Rational Unified Process   2003.06.15