반복적 개발을 사용하는 프로젝트에는 여러 번의 반복으로 이루어진 라이프사이클이 있습니다. 반복은 비즈니스 모델링, 요구사항, 분석 및 디자인, 구현, 테스트 및 배치 타스크의 느슨한 순차의 세트를 반복이 위치하는
개발 주기의 위치에 따라 다양한 비율로 통합합니다. 도입/인식(Inception) 및 정제(Elaboration) 단계의 반복은 관리, 요구사항 및 디자인 활동에 중점을 두고 구현/구축(Construction)
단계의 반복은 디자인, 구현 및 테스트에 중점을 두며 전이(Transition) 단계의 반복은 테스트 및 배치에 초점을 맞춥니다. 반복은 시간
제한(timeboxing) 방식으로 관리되어야 합니다. 다시 말해, 반복에 대한 스케줄이 고정되고 해당 스케줄에 맞추도록 반복의 컨텐츠 범위가 적극적으로 관리되어야 합니다.
초기 디자인은 주요 요구사항 면에서 결함이 있을 가능성이 많습니다 디자인 결함을 늦게 발견하면 비용이 초과되고, 일부 경우에는 프로젝트가 취소되기도 합니다.
모든 프로젝트에는 연관된 위험성 세트가 있습니다. 라이프사이클의 초기에 위험성을 피했는지 확인할 수 있으면 계획을 더 정확하게 작성할 수 있습니다. 시스템을 통합하려고 하기 전에는 많은 위험성이 발견되지 않습니다.
개발 팀이 얼마나 많은 경험을 가지고 있느냐에 관계없이 모든 위험성을 예측하는 것은 불가능합니다.
폭포수형 라이프사이클에서는 라이프사이클의 후반부까지 위험성을 피했는지 여부를 확인할 수 없습니다.
반복적 라이프사이클에서 주요 위험성 목록을 기반으로 하여 반복에 개발되는 증분을 선택합니다. 반복을 통해 테스트된 실행 파일을 생성하므로 대상 위험성을 완화했는지 여부를 확인할 수 있습니다.
반복적 접근 방식은 여러 가지 이유로 인해 선형 또는 폭포수형 접근 방식보다 일반적으로 우수합니다.
-
요소가 점차적으로 통합되므로 위험성 요소가 빨리 완화됩니다.
-
요구사항 및 전술 변경이 수용됩니다.
-
제품 개선 및 정제가 용이해져서 더욱 견고한 제품이 생성됩니다.
-
조직은 이 방법을 통해 학습하고 프로세스를 개선할 수 있습니다.
-
재사용가능성이 증가됩니다.
어떤 고객은 다음과 같이 말했습니다. "폭포수형 접근 방식을 사용하면 프로젝트 종료에 가까와질 때까지, 경우에 따라서는 통합 과정 도중까지 모든 것이 괜찮아 보입니다. 그러다가 모든 것이 무너집니다. 반복적 접근
방식을 사용하면 오랫동안 사실을 숨기기 어렵습니다."
프로젝트 관리자는 종종 반복 방법을 끝없는 해킹으로 간주하여 이에 반대합니다. Rational Unified Process에서 반복 방법은 상당히 제어됩니다. 반복은 수, 지속 기간 및 목표로 계획됩니다. 참가자의
타스크 및 책임이 정의됩니다. 객관적인 진행상태 척도가 캡처됩니다. 한 반복에서 다음 반복까지 일부 재작업이 발생하지만 이 또한 철저하게 제어됩니다.
많은 위험성이 통합 중에만 처리되고 발견되므로 반복 방법을 사용하면 위험성을 더 빨리 완화할 수 있습니다. 초기 반복을 전개할 때 프로젝트를 다각적인 측면(도구, 사용 소프트웨어, 인력 스킬 등)으로 연습함으로써
모든 원칙을 검토합니다. 인지된 위험성이 위험하지 않다고 판명되거나 뜻밖의 새로운 위험성이 나타날 수 있습니다.
결국 통합은 하나의 "폭발(big bang)"이 아니며, 요소가 지속적으로 통합됩니다. 실제로 반복 방법은 거의 지속적인 통합입니다. 길고 불확실하고 어려웠던 시간(프로젝트 후반에 전체 노력의 최대 40%를
차지함)과 정확하게 계획하기 어려웠던 사항이 아주 작은 수의 요소로 통합을 시작하는 여섯 개에서 아홉 개의 더 작은 통합으로 나뉩니다.
요구사항은 일반적으로 시간이 지남에 따라 변경될 것이기 때문에 반복적 접근 방식에서는 변경 요구사항을 고려하게 됩니다.
요구사항 및 요구사항 "변경"은 항상 전달 지연, 스케줄 초과, 고객 불만, 개발자 좌절 등 프로젝트에 대한 문제의 주된 원인이 되어 왔습니다. 25년 전 Fred Brooks는 "하나를 버리도록 계획하십시오.
어차피 그렇게 됩니다."라고 주장했습니다. 사용자는 도중에 마음을 바꾸기 마련입니다. 이는 사람의 본성입니다. 사용자에게 원래 가정한 대로 시스템을 받아들이도록 강요하는 것은 잘못된 일입니다. 컨텍스트가 변하므로
사용자의 마음도 변합니다. 사용자는 환경 및 기술에 대해 더 자세히 배우며 개발되고 있는 제품의 중간 시연을 보게 됩니다.
반복적 라이프사이클은 관리자에게 제품에 전술적인 변경을 작성하는 방법을 제공합니다. 예를 들어, 기존 제품과 경쟁하기 위해 경쟁사의 움직임에 더욱 빠르게 대응하도록 축소 기능성의 제품을 릴리스하기로 결정하거나 해당
기술을 수용하기 위해 다른 벤더를 채택할 수 있습니다.
또한 반복은 중간에 기술적 변경을 허용합니다. 일부 기술이 변경되거나 새 기술이 발표되어 표준이 되면 프로젝트에서 이를 이용할 수 있습니다. 특히 플랫폼 변경 및 하위 레벨 하부 구조 변경의 경우가 이에
해당합니다.
여러 반복에 걸쳐 오류가 정정되므로 반복적 접근 방식은 더 견고한 아키텍처를 생성합니다. 제품이 초기 반복 중에 성숙되면 초기 문제점이 발견됩니다. 제품 출시 직전에 발견되는 것과는 대조적으로 성능 병목 현상이
발견되고 감소될 수 있습니다.
프로젝트의 끝부분에서 테스트를 한 번 수행하는 것과는 대조적으로 반복적으로 개발하는 것은 보다 철저하게 테스트된 제품을 생성합니다. 중요한 기능은 여러 반복으로 테스트될 기회를 많이 가졌고 테스트 자체 및 테스트
소프트웨어가 성숙할 시간이 있었습니다.
개발자는 진행하면서 학습할 수 있고 전체 라이프사이클 중에 다양한 역량 및 전공을 적용할 수 있습니다.
단지 계획을 작성하고 스킬을 향상시키기 위해 오랜 시간을 기다리는 대신, 테스터는 테스트 및 기술 문서 작성을 빨리 시작합니다. 추가 훈련 또는 외부 도움에 대한 요구가 초기 반복 평가 검토에서 발견될 수
있습니다.
프로세스가 개발됨에 따라 프로세스 자체가 개선되고 정제될 수 있습니다. 반복 종료 시 평가는 제품 스케줄 관점에서 프로젝트의 상태를 보는 것만이 아니라 다음 반복에서 보다 잘 수행하기 위해 조직 및 프로세스에
변경되어야 하는 사항을 분석하기도 합니다.
반복적 라이프사이클은 재사용을 용이하게 합니다. 모든 공통성을 미리 식별하는 것과 비교할 때 부분적으로 디자인되거나 구현되었기 때문에 공통 부분을 식별하기가 쉽습니다.
재사용가능한 부분을 식별하고 개발하는 것은 어렵습니다. 초기 반복의 디자인 검토를 통해 소프트웨어 설계자가 예상치 않은 잠재적 재사용을 식별할 수 있게 하며, 연속적인 반복으로 이 공통 코드를 한층 더욱 더
개발하고 성숙시킬 수 있게 합니다.
반복 방법 사용은 상용 제품의 이용을 용이하게 합니다. 이를 선택하고 통합하며 아키텍처에 맞는지 검증할 수 있는 여러 개의 반복이 있습니다.
|