11.0 폭포수 대 주기적 프로젝트 관리(4부) – 프로젝트 수명 주기 및 결과

주기적인 프로젝트 관리 방법 #

위에서 논의한 문제로 인해 최근 몇 년 동안 프로젝트 관리의 다양한 대안 기술이 개발되었습니다. 이러한 기술은 정보 기술 개발 이니셔티브에 특히 적합합니다.

주기적 프로젝트 관리 일련의 짧고 순차적인 주기를 통해 프로젝트의 목표를 달성하는 방법입니다. 각 주기는 짧고 이상적으로는 한 달 미만입니다. 각 주기는 프로젝트의 일부를 완료합니다. 각 주기에는 분석, 설계, 구현 및 테스트가 포함됩니다. 이는 이러한 각 작업이 고유한 단계에서 발생하는 폭포식 접근 방식과 상당히 다릅니다. 또한 폭포식 접근 방식은 개념, 설계, 구현 및 테스트를 위한 제한된 수의 고유한 순간을 지정합니다. 이것은 순환적 접근 방식에서 여러 번 연속적으로 발생합니다.

이해 프로젝트 관리 소프트웨어 주기 #

다양한 소프트웨어 구성 요소가 주기 전체에 걸쳐 구현되므로 자체 포함됩니다. 각 주기는 완료 후 평가됩니다. 이해도가 높아진 결과 프로젝트에 대한 새로운 또는 대체 요구 사항이 나타나면 이를 포함하도록 미래 주기의 활동을 조정합니다.

주기는 일정의 설정 또는 수정으로 시작됩니다. 그런 다음 사이클의 출력 요구 사항이 평가됩니다. 설계가 개발, 코딩 및 검증됩니다. 그 후 평가가 이루어지며 경우에 따라 새로운 프로그램이 구현됩니다. 다음으로 프로젝트의 후속 구성 요소를 완료하기 위해 다음 주기가 시작될 수 있습니다. (주기적 기법과 그 차이점에 대한 더 자세한 논의는 예를 들어 Kroll, 2004; Chromatic, 2003; Stapleton, 2002를 참조하십시오.)

다음은 순환 방법을 사용할 때의 주요 이점입니다.

  • 개선된 제품 품질 및 기능 구현;
  • 개선된 제품 품질 및 기능 구현;
  • 보다 현실적인 시간 및 비용 추정
  • 프로젝트 팀의 부담이 적습니다.
  • 더 높은 품질.

앞의 장에서는 프로젝트의 초기 단계에서 필요한 기능을 적절하게 정의하는 것이 얼마나 어려운지 또는 불가능한지를 보여줍니다. 순환 기술은 일련의 짧은 주기로 필요한 기능을 구현합니다. 각 주기는 필요한 기능의 작은 부분을 조사할 뿐만 아니라 설계, 구현 및 테스트합니다. 설계, 실행 및 테스트의 빠른 연속은 품질 향상에 매우 중요합니다. 결과적으로 팀은 변화를 일으킬 수 있는 위치에 있습니다. 디자인이 실제로 작동하지 않으면 주기 전체에 걸쳐 명백해져서 수정이 가능합니다. 또한 이러한 종류의 작업을 통해 소비자는 변경을 요청할 수 있습니다.

품질 유지 #

주기적 프로젝트 관리가 품질을 향상시키는 또 다른 이유는 각 주기마다 클라이언트, 디자이너 및 프로그래머 간의 긴밀한 협력이 필요하기 때문입니다. 여러 분야의 팀이 함께 솔루션을 개발하고 실행합니다. 클라이언트는 주로 요구 사항 개발 초기에 참여합니다. 다음으로 디자이너가 디자인을 만들고 마지막으로 프로그래머가 소프트웨어를 만듭니다. 프로젝트 리더는 서로 다른 모든 당사자 간의 연락 담당자 역할을 하며 제공된 정보가 적절한 수신자에게 전달되도록 할 책임이 있습니다. 실제로 많은 프로그래머와 디자이너는 소프트웨어 개발 프로세스 전체에 걸쳐서만 다시 나타나는 클라이언트를 만나지 않습니다.

프로젝트 관리의 순환적 기술은 예술 또는 연구 계획과 같이 최종 목표를 사전에 명확하게 정의할 수 없는 프로젝트에 특히 적합합니다. 최종 사용자를 포함하는 다양한 팀과 주기적으로 작업하면 팀이 프로젝트의 진정한 목적과 이를 달성하는 최선의 방법을 결정할 수 있습니다. 각 주기는 반성과 수정의 기회를 제공합니다.

폭포수 프로젝트의 경우 대상이 미리 정의됩니다. 초기 목표에 대한 성찰은 가능성이 적습니다. 처음에 형성된 목표는 결코 (완전히) 실현되지 않으며, 원래 구상된 목표도 실현된 목표도 정확히 의도한 것이 아닐 수 있습니다.

마지막으로 주기적 프로젝트 관리 방법은 클라이언트가 수락 테스트를 수행하기 때문에 우수한 결과를 제공합니다. 또한 처음부터 고성능 기능의 기준으로 테스트를 포함함으로써 품질이 향상됩니다. 따라서 프로그래머는 코드를 작성하기 전에 ‘실패한 테스트'(또는 단위 테스트)를 만들어야 합니다. 실패한 테스트를 통과한 코드만 허용되는 것으로 간주됩니다.

일관된 테스트 #

테스트 지향 작업은 프로그래머가 새 코드를 작성하기 전에 버그가 없음을 입증해야 합니다. 그들은 코딩을 시작하기 전에 잠재적인 결함을 식별할 테스트(테스트 실패)를 만들어 이를 수행합니다. 사탕 기계에서 받을 적절한 양의 변경을 결정하기 위해 소프트웨어를 개발해야 하는 경우를 고려하십시오. 시작하려면 변경을 일으킬 수 있는 기능이 있는지 확인해야 합니다. 이 기능을 ‘변화 주기’라고 할 수 있습니다. 간단한 테스트를 실행하면 ‘변경하기’ 기능이 아직 존재하지 않는다는 것을 알 수 있습니다. 프로그래머가 함수를 생성했지만 아직 어떤 내용도 제공하지 않으면 테스트는 통과할 것입니다.

다음 단계는 품목을 구매할 때 기계가 정확한 금액을 반환하는지 확인하는 것입니다. 기계에 60센트를 넣고 50센트짜리 품목을 구입하십시오. 함수가 비어 있기 때문에 테스트가 실패합니다. 그 후 프로그래머는 코드를 작성합니다. 그는 ‘잔돈 주기’ 기능에서 반환할 잔돈의 양이 기계에 넣은 돈에서 선택한 사탕의 비용을 뺀 것과 같다고 지정합니다. 이제 테스트가 성공적으로 통과해야 합니다. 프로그램의 각 구성 요소에 대해 이 절차를 반복해야 합니다.

코드는 기술적으로 테스트되어야 할 뿐만 아니라; 기능도 테스트해야 합니다(즉, 승인 테스트). 코딩을 시작하기 전에 클라이언트는 개발할 기능이 승인될 수 있는 기준을 설정합니다(예: 컴퓨터가 특정 사용자 작업에 얼마나 빨리 반응해야 하는지). 그 전에는 추가 기능이 승인될 수 있는 기준을 정의하는 것이 매우 복잡하고 시간이 많이 소요되는 것으로 판명되었습니다. 그럼에도 불구하고 테스트에 소비자의 적극적인 참여는 프로젝트의 성공에 매우 중요합니다.

시간 및 비용 견적 #

구현될 기능을 이해하는 것은 주기적 프로젝트를 시작할 때 미리 결정되지 않습니다. 사용 가능한 시간이 제공됩니다. 프로젝트의 방향에 대한 합의가 이루어지고, 그 과정 전반에 걸쳐 생성될 프로그램 측면에서 무엇이 정말로 필요하고 유익하며 실현 가능한지 설정됩니다. 구현해야 하는 기능이 설정된 목표가 아니기 때문에 주기적 프로젝트는 필요한 시간과 그에 따른 돈이 통제 불능 상태가 될 수 있는 위험을 최소화합니다. 이 시나리오를 피하기 위해 가용 시간을 시작점으로 활용하고 그 시간 동안 예상할 수 있는 합리적인 시간이 프로세스 전반에 걸쳐 설정됩니다.

또한 주기적 프로젝트 관리 기법은 프로젝트 팀에게 훨씬 더 적합합니다. 팀은 할당된 시간 내에 할 수 있는 모든 작업을 수행하지만 불합리한 마감일을 달성하거나 부족한 예산 내에서 운영해야 한다는 압박을 받지 않습니다.

또한 주기적 기술은 외국 공급자의 관리를 단순화합니다. 폭포수 접근 방식을 사용하면 공급업체의 성과에 관계없이 프로젝트가 완료될 때까지 프로젝트가 단일 공급업체에 의존하게 될 수 있습니다. 각 주기 또는 순환 작업 기술에 따라 공급될 각 구성 요소에 대해 새로운 계약을 체결하고 필요한 경우 공급업체를 변경하는 것이 이론적으로 가능합니다.