가이드라인: 소프트웨어 개발 계획
이 가이드라인은 반복적 개발 주기에 맞게 소프트웨어 개발 계획을 작성하는 데 필요한 일부 도움말을 제공합니다. 전형적인 폭포수형 검토 시퀀스를 반복적 접근 방식에 맞추는 방법에 대해서도 논의합니다.
관계
기본 설명

각 반복 길이 결정

반복은 모든 주요 원칙을 거쳐 대부분의 경우 불완전하지만 실행 가능한 시스템인 릴리스가 되는 완전한 미니 프로젝트로 정의되어 왔습니다. 주기[편집, 컴파일, 테스트, 디버그]가 반복처럼 보이지만 이는 여기서 의미하는 바가 아닙니다. 보다 많은 시스템 요소를 점진적으로 통합하고 테스트하는 일일 또는 주별 빌드도 반복처럼 보이지만 여기에서 사용하는 용어로 이는 반복의 일부일 뿐입니다.

반복은 계획 및 요구사항으로 시작하고 내부 또는 외부 릴리스로 종료됩니다.

얼마나 빨리 반복할 수 있는가는 대부분 개발 조직의 크기에 따라 다릅니다.

예제:

  • 다섯 명의 인원인 경우 월요일 아침에 일부 계획을 수행하고, 매일 함께 작업하면서 진행상태를 모니터하고 타스크를 다시 할당하며, 목요일에 빌드를 시작하여 금요일 저녁까지 반복을 완료할 수 있습니다.
  • 그러나 20명의 인원으로 이 기간에 수행하는 것은 매우 어렵습니다. 작업을 분배하고, 하위 그룹 사이를 동기화하고, 통합하는 등의 작업에 보다 많은 시간이 걸립니다. 한 번의 반복에 3 - 4주가 소요될 수 있습니다.
  • 인원이 40명이면 "뇌에서 말단까지 신경이 유입되는" 데에만도 벌써 1주일이 걸립니다. 중간 관리 레벨이 생기고 목표를 공통으로 이해하기 위해 보다 정규 문서와 더 많은 의식(ceremony)이 필요합니다. 3개월 정도가 보다 적당한 반복 길이입니다.

안정적이고 성숙한 조직 구성을 포함하여 반복적 접근 방식을 사용하는 조직의 숙지 정도, 팀이 코드(예: 분배된 CM)를 관리하기 위해 사용 중인 자동화 레벨, 정보 분배(예: 내부 웹), 테스트 자동화 등의 다른 요소가 작용합니다.

또한 계획, 동기화, 결과 분석 등 반복의 일부 고정된 오버헤드가 있음에 유의하십시오.

따라서 한편으론 반복적 접근 방식의 대단한 이점을 확신하며 맹렬히 반복하려 하지만 조직의 인적 한계에 부딪히게 됩니다.

다음은 일부 경험적 데이터입니다.

SLOC 개발자 수 반복 지속 기간
10,000 5 1주일
50,000 15 1개월
500,000 45 6개월
1,000,000 100 1년

  • 6개월을 초과하는 반복은 프로젝트를 계속해서 추적하기 위해 중간 이정표를 빌드할 필요가 있습니다. 반복의 범위를 줄여 반복 길이를 감소시키고 초점을 명확히 하십시오.
  • 12개월을 초과하는 반복은 반복이 연간 재정 주기에 달하기 때문에 자체적인 위험성이 있습니다. 지난 12개월 동안 가시적 결과를 산출하지 못한 프로젝트는 자금을 잃을 위기에 처합니다.
  • 1개월 미만의 반복은 주의깊게 살펴야 합니다. 일반적으로 단기 반복은 포함할 새 기능성의 정도와 제품의 참신도가 낮은 구현/구축(Construction) 단계에 보다 적합합니다. 단기 반복은 정규 분석 또는 디자인을 거의 하지 않거나 전혀 하지 않을 수 있으며 단지 잘 이해된 기능성을 점진적으로 개선할 수 있습니다.
  • 반복의 길이가 모두 같을 필요는 없습니다. 길이는 목표에 따라 다릅니다. 일반적으로 정제(Elaboration) 반복이 구현/구축(Construction) 반복보다 깁니다. 한 단계 내에서는 일반적으로 반복의 길이가 동일합니다(이는 계획을 보다 수월하게 함).

대강의 계획에서 반복의 수가 일단 결정되면 각 반복의 컨텐츠를 정의할 필요가 있습니다. 각 반복의 마지막에 제품을 규정할 이름이나 제목을 찾아 보다 나은 초점을 얻을 수 있게 도와 주는 것도 좋은 생각입니다.

예제 개인용 전화 교환에 필요한 반복

  • 반복 1: 로컬 통화
  • 반복 2: 외부 통화 및 가입자 관리 추가
  • 반복 3: 음성 메일 및 전화 회의 추가

반복 수 결정

매우 간단한 프로젝트에는 단계별로 반복이 하나만 있을 수 있습니다.

  • 발전 주기 예제의 경우 도입/인식(Inception) 단계에는 개념 검증 프로토타입 또는 사용자 인터페이스 실물 모형을 산출할 수 있는 반복이 하나 있거나 전혀 없을 수 있습니다.
  • 정제(Elaboration) 단계에서 아키텍처 프로토타입을 생성하는 한 반복
  • 구현/구축(Construction) 단계에서 제품을 빌드하는 한 반복(최대 "베타" 릴리스까지)
  • 전이 단계에서 제품을 완료하는 한 반복(전체 제품 릴리스)

보다 크기가 큰 프로젝트의 경우 초기 개발 주기의 기준은 다음과 같습니다.

  • 도입/인식(Inception) 단계의 한 반복(프로토타입을 생성할 수 있음)
  • 정제(Elaboration) 단계에서 아키텍처 프로토타입과 아키텍처 기준선에 각각 하나씩 두 개의 반복
  • 구현/구축(Construction) 단계에서 부분 시스템을 노출하고 완성시키는 두 개의 반복
  • 전이(Transition) 단계에서 초기 운용 능력으로부터 전체 제품 릴리스까지 이동하는 한 반복

대규모 프로젝트의 경우에는 미지의 사항, 새 기술 및 가능성이 많으므로 다음과 같을 수 있습니다.

  • 도입/인식(Inception) 단계에서 보다 많은 프로토타입을 허용하는 추가 반복
  • 정제(Elaboration) 단계에서 탐색할 다른 기술을 허용하는 추가 반복
  • 구현/구축(Construction) 단계에서 제품의 얇은 크기로 인한 추가 반복
  • 전이(Transition) 단계에서 오퍼레이션 피드백을 허용하는 추가 반복

따라서 개발 주기에 대해 다음과 같습니다.

  • 낮음: 3 반복 [0,1,1,1]
  • 일반: 6 [1, 2, 2, 1]
  • 높음: 9 [1, 3, 3, 2]
  • 매우 높음: 10 [2, 3, 3, 2]

따라서 일반적으로 3 - 10 반복을 사용하도록 계획하십시오. 그러나 상위 및 하위 경계가 이상 상황을 의미하므로 개발에서는 6 - 8 반복을 사용합니다.

위험성, 크기, 복잡도에 따라 여러 변형이 가능합니다.

  • 제품이 일부 완전히 새로운 도메인에 대한 것인 경우 도입/인식(Inception) 단계에서 개념을 견고하게 하거나, 고객이나 사용자에게 다양한 실물 모형을 표시하거나, 제안 요청에 대한 분명한 응답을 빌드하기 위해 일부 반복을 추가해야 할 수 있습니다.
  • 새 아키텍처를 개발해야 하거나, 많은 양의 유스 케이스 모델링이 있거나, 매우 도전적인 위험성이 있는 경우에는 정제(Elaboration) 단계에서 2 또는 3 반복을 계획해야 합니다.
  • 제품이 크고 복잡하며 장기간에 걸쳐 개발된 경우 구현/구축(Construction) 단계에서 셋 이상의 반복을 계획해야 합니다.
  • 시장 진입 시간을 최소화해야 하기 때문에 기능성 세트가 줄어든 제품을 전달해야 하는 경우 또는 사용 기간 후 일반 사용자에 대한 작은 적응 부분이 많이 필요할 수 있다고 느끼는 경우에는 전이(Transition) 단계에서 여러 반복을 계획해야 합니다.

전형적인 폭포수형 검토 시퀀스를 반복적 접근 방식에 맞추기

폭포수형 라이프사이클 프로젝트에 대한 기본 검토 시퀀스는 중요한 중간 산출물이 완료될 때 다음과 같은 주요 단일 검토를 합니다.

  • 시스템 요구사항 검토(SRR), 시스템 스펙 완료 시
  • 소프트웨어 스펙 검토(SSR), 소프트웨어 요구사항 스펙 완료 시
  • 예비 디자인 검토(PDR), 소프트웨어 디자인 설명의 아키텍처 디자인 섹션 완료 시
  • 주요 디자인 검토(CDR), 소프트웨어 디자인 설명의 자세한 디자인 섹션 완료 시

Rational Unified Process(RUP)에서 해당 중간 산출물의 일부는 각 반복에서 완료될 때 검토되지만 주요 이정표(및 검토)는 도입/인식(Inception), 정제(Elaboration), 구현/구축(Construction) 및 전이(Transition) 단계의 완료에 맞춰집니다. RUP를 채택하려는 프로젝트 관리자는 계약상 의무로 인해 명백한 이 충돌을 조정할 방법을 찾아야 할 수 있습니다. 프로젝트 관리자는 단계 및 반복 기반의 접근 방식이 사실 이론상으로는 프로젝트 진행상태에 대한 상당한 가시성을 제공하고 위험성을 감소시켜 SRR, SSR 등의 필요성이 없다는 점을 고객에게 확신시켜야 합니다. 그러나 항상 이렇게 할 수는 없으므로 프로젝트 관리자는 적절한 시점에 이런 검토 스케줄을 잡아야 합니다. RUP에서는 중요한 중간 산출물(실제로 RUP에서 이에 해당하는 것)이 본질적으로 완료되는 시점이 단계나 반복과 항상 깔끔하게 맞아 떨어지는 것은 아니지만 이 시점을 찾는 것이 가능합니다.

이는 요구사항, 디자인 등에 소모될 관련 노력이 RUP에서 (이상적인) 폭포수형 라이프사이클에서와 대략 동일하다(노력의 분배 방식은 다름)고 가정하여 수행됩니다. 결과는 다음과 같습니다.

  • SRR(주로 비전에 관한)은 도입/인식(Inception) 단계의 마지막에 계획할 수 있습니다.
  • SSR(주로 소프트웨어 요구사항 스펙에 관한)은 정제(Elaboration) 단계의 대략 1/3 지점에 계획할 수 있습니다.
  • PDR(주로 소프트웨어 아키텍처 문서에 관한)은 정제 단계의 마지막에 계획할 수 있습니다.
  • CDR(주로 디자인 모델에 관한)은 구현/구축(Construction) 단계의 대략 1/3 지점에 계획할 수 있습니다.

효율성을 위해 프로젝트 관리자는 고객과 상의하여 이러한 검토를 규정된 RUP 검토와 결합하도록 시도해야 합니다. SRR 및 PDR의 경우 이는 확실히 가능해서 라이프사이클 목표 이정표 검토 및 라이프사이클 아키텍처 검토와 각각 결합할 수 있습니다.

프로젝트 조직

소프트웨어 프로세스가 프로젝트 특성의 영향을 받는 것처럼 프로젝트 조직도 마찬가지입니다. 다음에 나열된 사항과 같은 요인의 영향을 반영하도록 여기에 제시된 기본 구조(아래 그림 참조)를 조절해야 합니다.

  • 비즈니스 컨텍스트
  • 소프트웨어 개발 노력의 규모
  • 제품의 참신도
  • 응용프로그램 유형
  • 현재 개발 프로세스
  • 조직 요소
  • 기술 및 관리 복잡도

이들은 조직이 전체적으로 새 개발 프로세스를 어떻게 채택해야 하는지 분석할 때의 중요 구별 요인으로, 여기서는 프로젝트 구조 선택에 대한 이들의 영향을 검토합니다. 아래의 그림은 팀 구조에 책임을 지정하는 방법을 표시하는 기본 프로젝트 조직을 표시합니다.

팀 구성원에 책임을 지정하는 방법을 표시하는 컨텍스트 다이어그램

기본 프로젝트 조직을 표시하는 그림. 역할의 순서 지정에서 우선순위나 권한에 대해서는 아무런 의미가 없음에 유의하십시오.

이 그림은 프로젝트 레벨 역할 및 책임을 팀의 구조에 어떻게 맵핑해야 하는지 고려하는 시작점입니다. 또한 역할(노란 상자에 표시된)이 개별적인 것이 아니고 한 개인(또는 한 팀)이 프로젝트에서 착용할 수 있는 "모자"와 같은 개념임을 강조합니다. 이는 일부 역할(예: 프로젝트 관리자)이 두 번 이상 나타나기 때문입니다. 이같은 사실은 RUP에 정의된 프로젝트 관리자의 동작이 일정 시기에 둘 이상의 팀에서 나타날 수 있음을 의미합니다. 예를 들어, 대규모 프로젝트에서는 작업분류체계(WBS)에 기초하여 상태 보고서를 준비하는 타스크를 관리 팀의 한 개인에게 위임할 수 있습니다. 그러나 이는 RUP가 프로젝트 관리자라는 역할에 부여하는 책임입니다.

소규모 프로젝트에서는 프로젝트 관리자로 지명된 한 개인이 프로젝트 관리자라는 역할의 모든 타스크를 수행하며 이 경우 관리 팀은 소프트웨어 관리 팀과 연합됩니다. 팀 구조의 선택은 프로젝트의 특성과 크기의 영향을 받지만 어느 정도는 대부분 일반적인 규칙으로 조절해야 합니다.

  • 소규모 팀은 대개 보다 생산적이지만 대규모 프로젝트에서는 팀 간의 상호작용 정도에 대해 밸런스를 조절해야 합니다.
  • 깊은 계층 구조는 피해야 합니다.
  • 관리자나 팀 리더의 제어 범위는 5 - 9명으로 제한해야 합니다.
  • 소프트웨어 개발 팀 구조는 소프트웨어 아키텍처로 구동해야 합니다. 서브시스템 간의 결합력이 낮고 응집도가 높은 좋은 구조는 팀이 병행하여 보다 효과적으로 작업할 수 있게 합니다.
  • 유닛 테스트 이외의 테스트는 이상적으로 개발 팀과 별도의 팀이 수행해야 합니다. 그러나 매우 작은 프로젝트에서 이는 경제적 측면에서 이익이 되지 않음에 유의하십시오.
  • 구조는 모든 팀과 개인에게 명확하게 정의된 권한 및 책임을 부여해야 합니다. 이는 계층 구조가 3 레벨을 초과하는 경우에 특히 중요합니다. 이러한 구조 중앙에서의 관리자 및 팀 리더는 기술 및 관리 타스크와 밸런스를 조절하는 데 필요한 사항이 무엇인지 이해해야 합니다.
  • 구조는 직원의 능력, 경험 및 동기를 지원해야 합니다. 예를 들어, 단일 팀이 중간 전환 없이 분석, 디자인 및 구현을 수행한다고 가정하면 필요한 모든 역량을 발휘해야 합니다. 숙련된 분석가가 반드시 좋은 구현자는 아닙니다.
  • 팀 구조는 엄격하면 안됩니다. 개인은 프로젝트의 수명 중 팀 사이를 이주하며 프로젝트의 강조 사항이 한 단계에서 다른 단계로 이동함에 따라 팀의 책임이 변경되기 때문입니다.

기본 조직에 대한 근거는 [ROY98]에서 자세히 설명합니다. 특히 소프트웨어 평가 팀에 대한 개발 책임 지정에서는 개발 프로젝트의 모든 팀 중에서 소프트웨어 평가 팀이 소프트웨어에 가장 크게 노출된다고 인식합니다(사용자가 이를 보기 때문).

프로젝트의 수명 중 조직은 프로젝트 계획에서 캡처한 작업분류체계(WBS)를 지원하도록 발전합니다. 이는 [ROY98]에서 가져온 다음 그림에 표시됩니다.

프로젝트의 라이프사이클 중 팀 발전을 표시하는 다이어그램

이 발전은 각 단계에서 다른 타스크 세트를 강조합니다.

  • 도입/인식(Inception) 팀: 계획이 모든 관점의 일치를 나타내도록 다른 팀의 충분한 지원을 받아 계획에 초점을 맞춘 조직
  • 정제(Elaboration) 팀: 프로젝트의 원동력이 소프트웨어 아키텍처 팀에 있고 필요에 따라 소프트웨어 개발 및 소프트웨어 평가 팀의 지원으로 안정적인 아키텍처 기준선을 이루는 아키텍처 중심 조직
  • 구현/구축(Construction) 팀: 대부분의 타스크가 소프트웨어 개발 및 소프트웨어 평가 팀에 있으며 균형 잡힌 조직
  • 전이(Transition) 팀: 사용 피드백으로 개발 타스크를 구동하는 고객 중심 조직

이와 같은 발전 단계 중 팀 사이를 이주해도 지식 및 능력은 프로젝트에 보유됩니다. 예를 들어, 정제(Elaboration)가 완료되면 일부 아키텍처 팀 구성원은 개발 팀으로 흩어지거나 팀 리더로 활동하거나 아키텍처 '비전'을 개발에 도입할 수 있습니다. 이후에도 구현/구축(Construction) 단계가 완료되면 초점이 평가 팀으로 옮겨가고 직원은 개발 팀에서 평가 팀으로 이동합니다. 이 단계에서는 프로젝트 '무게 중심'의 이동에 따른 아키텍처 팀의 영향력 감소를 허용하지 않는 아키텍처 무결성의 손실을 막는 것도 중요합니다. 일부 아키텍처 팀 구성원을 평가 팀으로 옮기는 것이 이를 위한 한 방법입니다.