폭포수 기술은 여러 단계로 구분됩니다. 프로젝트 리더는 프로젝트 계획의 각 단계에 필요한 시간(따라서 비용)에 대한 추정치를 포함해야 합니다. 우리는 이전에 모든 프로젝트에서 시간 추정이 본질적으로 문제가 있다는 점을 확인했으며, 프로젝트 초기에 시간 추정을 설정해야 하는 경우에는 더욱 그렇습니다. 소프트웨어 프로젝트에는 적합하지 않습니다. 정의 단계에서 질적으로 수용 가능한 기능 목록이 작성될 수 있는 가능성을 고려하십시오. 원칙적으로 이를 통해 프로젝트 팀은 각 기능을 개발하는 데 필요한 시간을 현실적으로 예측할 수 있습니다. 그러나 실제로는 공정한 근사치를 제공하기에는 불확실성이 너무 많습니다.
그러나 실제로는 공정한 근사치를 제공하기에는 불확실성이 너무 많습니다.
- 기능이 개발된 후 클라이언트에 해당 기능이 필요하지 않은 것으로 판명되는 경우가 많습니다. 따라서 이 기능을 개발하는 데 소요된 시간은 헛된 것으로 간주될 수 있습니다.
- 프로젝트가 진행되는 동안 요구 사항이 변경될 수 있습니다.
- 기능을 높은 비용으로 제공해야 합니까, 아니면 저렴한 비용으로 제공해야 합니까? 많은 구현 및 실현 기술이 있습니다.
- 기능은 기술적으로 어떻게 설계됩니까? 디자인은 그것을 만드는 데 필요한 시간에 큰 영향을 미칩니다.
- 기능은 어느 정도까지 높은 수준이어야 합니까? 예를 들어, 웹 애플리케이션은 항상 완벽하게 액세스할 수 있어야 합니까, 아니면 연간 몇 시간 동안 다운되도록 허용해야 합니까?
- 소프트웨어 문제를 감지하고 수정하는 데 필요한 시간은 몇 분에서 몇 주까지 다양합니다.
- 새 소프트웨어를 설치하고 고객의 현재 시스템과 통합하는 데 시간이 얼마나 걸리나요?
- 잠재적인 솔루션에 대한 정보가 부족하면 예상 시간에 더욱 영향을 미칩니다. 또한, 필요한 전문 지식을 습득하는 데 필요한 시간을 추정하는 것도 어렵습니다.
위 목록은 다양한 변수가 새로운 소프트웨어를 개발하는 데 필요한 시간에 영향을 미칠 수 있음을 보여줍니다. 프로젝트 시작 시 기능을 개발하는 데 필요한 시간 추정치는 종종 4배 너무 낮거나 4배 너무 높습니다. 이는 필요한 시간이 잘못된 추정보다 4배 더 많거나 4배 더 짧을 수 있음을 의미합니다. 프로젝트가 진행됨에 따라 이러한 추정치는 더욱 정확해집니다. 기능적인 디자인을 완성한 후 마진은 25%로 과하거나 너무 적습니다. 기능이 개발된 경우에만 높은 신뢰도로 추정치를 제공할 수 있습니다.
소프트웨어 위험#
프로젝트 관리 소프트웨어결코 완전히 오류가 없을 수는 없습니다. 널리 사용되는 잘 알려진 프로그램(예: Word, Excel, Explorer, OS X, PHP 및 Flash)의 경우에도 인터넷에는 알려진 결함 목록이 있습니다. 정기적으로 소프트웨어 버그를 수정하는 새 버전이 시장에 출시됩니다. 고객은 때때로 소프트웨어에 오류가 없기를 요구합니다. 그러나 현실적으로 그러한 목표는 소프트웨어를 완성하는 것을 불가능하게 만듭니다. 또한 소프트웨어 결함은 프로그램 자체에 내재되어 있지 않은 경우가 많습니다.
플래시는 교육용 게임을 만드는 데 사용되었습니다. 클라이언트는 게임을 파일로 받아 자신의 서버에 설치하는 데 동의했습니다. 프로젝트 과정에서 고객은 플레이어 경쟁력을 강화하기 위해 게임에 고득점 기능을 추가해 줄 것을 요청했습니다. 여기에는 PHP 스크립트 코드가 필요합니다. 게임 개발자는 Linux를 실행하는 자체 서버에서 스크립트 코드를 개발하고 테스트했습니다. 성공했습니다. 클라이언트는 게임과 스크립트 코드를 받았습니다. 그러나 클라이언트가 Windows 서버를 사용했으며 어떤 이유로 스크립트가 제대로 작동하지 않았습니다. 최고 성적은 유지되지 않았습니다. 프로그래머가 문제를 해결하려면 궁극적으로 일주일이 필요합니다. 알고 보니 PHP와 Windows가 항상 함께 잘 작동하는 것은 아닙니다. 대본 전체는 전혀 실수가 없었습니다! 그는 해킹을 통해 그것이 작동하도록 할 수 있었고 모두가 기뻐했습니다. 하지만 추가 일주일의 노동 비용은 누가 지불해야 합니까?
또 다른 소프트웨어 개발 프로젝트에는 교육용 애플리케이션 제작도 포함되었습니다. 문제는 소프트웨어가 개발자에게는 훌륭하게 작동했지만 클라이언트에게는 좋지 않았다는 것입니다. 다른 모든 가능성을 다 써본 후 프로그래머는 클라이언트를 방문하기로 결정했습니다. 알고 보니 클라이언트는 1990년대 초반부터 Pentium III 시스템을 실행하고 있었습니다. 컴퓨터의 속도 저하로 인해 소프트웨어 성능이 저하되었습니다. 게다가 프로그래머들은 Pentium III에서 소프트웨어를 시험해 보았고 잘 작동했습니다. 추가 조사 결과 고객의 PC가 바이러스 및 스파이웨어 감염으로 인해 느리게 실행되는 것으로 나타났습니다.
프로젝트 개발의 불확실성 관리#
위의 사례에서 나타난 불확실성은 프로세스를 복잡하게 만듭니다.프로젝트 계획 개발. 게다가 당사자들 간의 협상도 복잡해진다. 누군가는 수행해야 하는 추가 노동과 관련된 위험을 감수해야 합니다. 시간 단위로 결제하는 경우 모든 위험은 고객이 부담합니다. 정해진 수수료가 합의되면(보조금 지원 프로젝트의 경우) 소프트웨어 개발자가 위험을 부담합니다. 두 명 이상의 사람이 관련되면 상황은 더욱 복잡해집니다. 이 시나리오에서 프로젝트에 추가로 근무한 시간에 대한 비용은 누가 부담해야 합니까?
지연에 대한 책임을 누가 져야 하는지에 대한 논쟁이 자주 발생합니다. 책임자를 식별하기 어려운 경우가 많습니다. '지연'은 필요한 시간에 대한 잘못된 초기 추정으로 인해 발생했기 때문에 관련 당사자 중 누구도 책임이 없다고 생각할 수 있습니다. 과도한 프로젝트 시간과 누가 비용을 지불해야 하는지에 대한 문제는 정보 기술 산업에서 흔히 발생하는 논쟁의 원인입니다.
