개념: 반복
이 안내는 특히 소프트웨어 개발 측면에서 "반복"의 기본 개념과 해당 목적에 대해 설명합니다.
관계
관련 요소
기본 설명

반복의 개념

반복에는 제품 릴리스(안정적이고 실행 가능한 제품 버전 및 이 릴리스를 사용하는 데 필요한 기타 모든 주변 요소)가 생성되는 개발 활동이 포함됩니다. 따라서 개발 반복은 어떤 의미에서 모든 원칙(요구사항, 분석과 디자인, 구현 및 테스트)을 통과한 하나의 완벽한 시도로 볼 수 있습니다. 또한 반복은 그 자체로 소규모의 폭포수형 프로젝트와도 같습니다. 각 반복을 계획할 때마다 평가 기준이 설정됩니다. 릴리스는 시연 가능하며 계획된 기능을 갖습니다. 반복 지속 기간은 프로젝트의 크기와 특성에 따라 다르지만, 반복에 대한 통합 빌드 계획의 설명처럼 반복에 복수 빌드를 구성할 수 있습니다. 이는 RUP(Rational Unified Process)에서 권장하는 지속적인 통합 접근 방식에 따른 결과입니다. 즉, 유닛 테스트를 마친 컴포넌트를 사용할 수 있게 되고 통합된 후 빌드가 생성되어 통합 테스트를 받습니다. 이러한 방식을 통해, 반복이 진행됨에 따라 통합된 소프트웨어의 기능이 반복 계획 시 설정한 목적에 맞게 향상됩니다. 각 빌드 자체가 소규모 반복을 나타내며 차이점은 단지 필요한 계획와 수행된 평가의 형식성이라고 할 수 있습니다. 일부 프로젝트의 경우 빌드를 매일 구성하는 것이 편리하고 필요한 경우도 있을 수 있지만 이러한 경우 아주 작은 규모의 1인 프로젝트를 제외하고는 RUP가 정의하는 반복을 나타내지 않게 됩니다. 소규모의 복수 구성원 프로젝트의 경우에도(예를 들어, 다섯 명이 10,000행의 코드를 빌드하는 경우) 반복 지속 기간을 1주 미만으로 달성하기는 매우 어렵습니다. 해당 이유는 가이드라인: 소프트웨어 개발 계획을 참조하십시오.

반복의 이유

일반적으로 프로젝트는 각 원칙을 순서대로 한 번씩만 진행하도록 구성되며 이를 통해 다음과 같은 폭포수형 라이프사이클이 생성됩니다.

이 다이어그램에는 비즈니스 모델링에서 배치까지 하나의 반복만 표시됩니다.

이러한 경우 일반적으로 구현 후반부에서 제품이 빌드되고 테스트가 시작될 때 비로소 통합이 '구축'됩니다. 결과적으로, 분석, 디자인 및 구현 단계에서 발견되지 않은 문제점이 나타나게 되어 프로젝트가 중단되며 동시에 장기간의 버그 수정 주기가 시작됩니다.

위험성은 적고 보다 유연한 진행 방법은 다양한 개발 원칙을 여러 번 수행하는 것입니다. 이 방법을 사용하면 요구사항을 보다 정확하게 이해하고 견고한 아키텍처를 엔지니어링할 수 있으며 개발 조직을 활용하고 점차적으로 완벽해지는 일련의 구현을 제공하게 됩니다. 이러한 개념을 반복 라이프사이클이라고 하며 프로세스 원칙 시퀀스에서의 각 패스를 반복이라고 합니다.

이 다이어그램은 각각 비즈니스 모델링에서 배치 과정을 거치는 세 개의 연속 반복을 보여줍니다.

따라서 개발 관점에서 볼 때 소프트웨어 라이프사이클은 소프트웨어가 점진적으로 개발되는 반복의 연속입니다. 각 반복은 실행 가능한 제품의 릴리스로 종결됩니다. 이 제품은 전체 비전의 서브세트이지만 일부 엔지니어링 또는 사용자 관점에서도 유용합니다. 각 릴리스에는 지원 중간 산출물(릴리스 설명, 사용자 문서, 계획 등)과 갱신된 시스템 모델이 함께 제공됩니다.

이 반복 접근 방식의 주요 결과는 앞에서 설명한 것처럼 중간 산출물이 시간이 지남에 따라 양적, 질적으로 모두 성장한다는 것입니다(다음 다이어그램 참조).

함께 표시된 텍스트에서 설명되는 다이어그램

개발 단계에서의 정보 세트 발전

보조 이정표

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