8.0 폭포수 대 주기적 프로젝트 관리(1부)

NS 폭포 모델 , 6단계 모델은 폭포수 모델입니다. 즉, 단계가 순차적으로 발생합니다. 폭포에 맞서 상류로 수영하는 것이 불가능하듯이 순수한 폭포수 기법은 폭포가 끝난 후 단계로 돌아가는 것을 방지합니다.

구현 단계에서 설계를 변경하여 구현을 중단하는 것은 이상적이지 않습니다. 폭포수 접근 방식은 다양한 이유로 소프트웨어 개발 프로젝트에 적합하지 않은 경우가 많습니다.

  • 소프트웨어 개발은 예술적 노력입니다. 모든 요구 사항(기능)을 예측하는 것은 사실상 어렵습니다.
  • 기능을 개발하는 데 필요한 시간을 추정하는 것은 매우 어렵습니다.
  • 프로젝트 수명 주기 동안 사용자는 모든 중간 결과를 테스트할 수 있어야 합니다.

소프트웨어 개발은 예술적 노력입니다 #

초심자에게 소프트웨어 개발은 발명보다 엔지니어링에 더 가깝습니다. 그러나 그것은 여러 가지 방법으로 발명과 관련이 있습니다. 창조의 과정에서 어떤 일이 일어날지 정확히 알 수 없습니다.

새로운 소프트웨어 개발을 담당하는 디자이너와 프로그래머는 그들이 제시하는 문제에 대한 답을 제시해야 합니다. 작업에 대한 많은 기술과 처방에도 불구하고 컴퓨터 코드 생성은 여전히 대부분 알려지지 않았으므로 예측할 수 없습니다. 프로그래머는 수십 개의 프로그래밍 언어로 작성되고 수천 개의 서로 다른 하드웨어 조합 및 소프트웨어 플랫폼에서 작동하는 수백만 개의 솔루션 중에서 선택할 수 있습니다. 이러한 유연성은 많은 이점을 제공하지만 프로젝트를 기존보다 관리하기 더 어렵게 만듭니다. 프로젝트 관리 (예: 건설 또는 건축 프로젝트).

구현 설정 #

폭포수 접근 방식은 요구 사항이 프로젝트의 정의 단계 . 이상적으로는 프로젝트의 나머지 기간 동안 이러한 기준에서 최소한의 추가 이탈이 발생해야 합니다. 소프트웨어 개발의 폭포수 접근 방식은 필요한 기능(요구 사항)을 분석하는 데 상당한 노력을 기울일 필요가 있습니다. 그 결과 기능적 디자인이 생성됩니다(기능적 디자인에 대한 추가 정보는 I 참조). 소프트웨어 설계자는 기능적 설계를 참조로 사용하여 설계 프로세스 전반에 걸쳐 기술 설계를 작성합니다. 또한 기술 설계는 필요한 기능을 실행하는 방법에 대한 지침을 제공합니다.

이것은 단순한 문제처럼 보일 수 있지만 다음 시나리오를 고려하십시오. 프로젝트의 일환으로 새로운 차량이 개발되고 있습니다. 능동적인 자동차 운전자로서 귀하는 자동차 요구 사항을 개발하는 임무를 맡고 있습니다. 당신은 다른 운전자들과 상의하고 완전한 목록을 작성합니다:

  • 차는 4명이 앉을 수 있어야 합니다.
  • 자동차는 운전자의 왼쪽 전방에 핸들이 있어야 합니다. • 자동차에는 브레이크 페달, 가속 페달 및 핸드 브레이크가 있어야 합니다.
  • 자동차의 헤드라이트는 흰색이어야 하고 후미등은 빨간색이어야 합니다. (분명히 실제 목록은 엄청날 것입니다)

디자인 및 모델링 #

디자이너는 목록을 가이드로 사용하여 새로운 디자인을 만들고 몇 달 후에 구성합니다. 길을 가다 보면 차가 멈춰 있는 것을 볼 수 있습니다. 당신은 당신의 목록에서 브레이크 등을 생략했다는 것을 깨달았습니다! 당신의 전화에 거의 폭발할 뻔한 자동차 제조업체의 엔지니어에게 재빨리 연락합니다. 당신은 그것이 사소한 조정이라고 주장합니다. 하지만 자동차 제조사들에게는 재앙이다. 이미 제조된 자동차는 완전히 분해하고, 브레이크 페달에서 뒤쪽으로 배선을 연장해야 하며, 차량의 뒤쪽은 브레이크등에 맞게 완전히 재설계되어야 하며, 이미 제조된 부트 해치는 폐기해야 하며 목록은 계속됩니다.

위의 시나리오가 우스꽝스러워 보이지만 소프트웨어 개발에서 거의 매일 일어나는 일입니다. 프로그래머는 생성되는 제품의 클라이언트, 고객 또는 사용자가 원하는 것을 정확히 이해하고 있다고 잘못된 가정을 합니다. 클라이언트는 소프트웨어 개발자가 가능한 가장 짧은 시간에 무엇이든 만들고 수정할 수 있다고 잘못 생각합니다. 이것이 소비자와 소프트웨어 개발자 사이의 경합의 주요 원인입니다.