Page History

폭포수 모델의 기원

...

배열된 다음 목표를 성공시켜나간다. 이렇게 배열된 맨 마지막 순서가 바로 성공이다.

또한 수행하는 업무를 전문적으로 만들며, 전문적인 롤이 폭포수모델의 단계와

일치한다. 경험정도도 반영되는데 일반적으로 초기에 경험많은 고참(착수,요구사항분석)이

참여하고 다음이 중간레벨(분석,설계) 그다음 직원이 코딩,유지보수등의 업무를 수행한다.

PM관점에서 폭포수 모델

폭포수 모델은 관리자에게 매우 매력적이다. 질서정연하고, 예측 가능한듯 하며(최소한 보고가능)

자원 할당을 쉽게 만들고 프로젝트 관리와 형상 관리 요구사항을 총족시키거나 충족시키도록 만들수 있다.

할일을 생성하고 완료로 옮기는일은 폭포수모델이나,스커럼,애자일등 모두가 

Task를 관리하는 기본적인 방법이다. 

완료로 옮기기위한 활동만을 우아하거나 고급스럽게 엄청난 시간들들여 하는것을 수없이 봐왔다. 

이것만 하는것은 소프트웨어를 만드는 중요한 기법들을 모두 무시하는것이다.

올바르게 만들어지고 있는가?  VS 완료되었는가?

WBS,칸반보드등 올바르게 만들어지고 있는가? 에 관심을 가지는경우를 거의 보지 못하였다. 

폭포수 모델

1. 착수단계 (+선택사항 연구)
2. 요구사항 분석(+대안 연구)
3. 기초설계(+기능명세)
4. 상세설계
5. 코딩(-상세 설계에 포함될수 있음)
6. 모듈테스트(-코딩단계에 포함될수 있음)
7. 시스템 테스트(검증)
8. 설치와 인도(확인)
9. 유지보수 운영 성능개선

...

• 지나치게 오래걸린다 : 문서 작업들과 승인 과정은 모두 빠른 개발을 방해한다. 산출문 문서는 생명주기 내내 '겉치레' 역활에 그치며 내재된 가치가 있다라고 생각한다.
• 최종사용자와 의사소통에서 생기는 틈 : 맥크래켄은 다음과 같이 말했다. 폭포수 모델의 생명주기는 진열대를 돌아다닐 기회도 주지 않고 슈퍼마켓 입구에서 고객이 점원에게 완벽하게 주문하도록 강요하는 슈퍼마켓과 비교할수 있다. (진열대를 돌아다니면, 가격을 비교할수도 있고, 쇼핑 목록에 없는 항목을 기억할수도 있고, 그냥 외식하러 가기로 결정할수도 있다)
• '어떻게'에서 분리된 '무엇' : 문제를 정의할 때까지 해결책을 미룬다는 생각도 구조적 분석과 설계의 신조 가운데 하나다. 물론 문제 정의를 먼저하고 해결책을 나중에 내는것은 논리적인 귀결이다. 하지만 불행히도 사람들은 현실에선 그런 식으로 행동하지 않는다. 사람들은 문제를 고려할때 보통 일정한 범위 안에서 가능한 해결책을 동시에 고려한다.
• 에러관리 : 모듈의 기능과 인터페이스에 대한 정의를 내리는 동안 발생 가능한 특정 에러 상황을 정의하는 것도 가능은 하다. 하지만 이렇게 에러에 대해 내부 반응을 정의하는 것은 설계자가 모듈의 상세 구현을 고려하고 있음을 의미하는 것이다. 이것은 추상화 원리를 위반하기도 하거니와 적절하지도 않다. 폭포수 모델 하향식 원칙에 위배되지만 초기 설계를 하면서 정의하고 사용해온 모듈의 인터페이스는 바뀔 가능성이 높다.(대부분 변경된다.)
• 고약한문제 : 합당한 문제는 정의될수있고, 해결책이 나올수 있다. 하지만 고약한 문제는 정형화되어 있지않으며, 해결책의 일부가 문제 공간안에 있다. 특히 문제를 해결하고 나서야 완전히 이해할수있다. 이것은 최종 해결책에 도달하기 전에 중간 결과를 반드시 얻어야 한다는 것을 뜻하거나, 아니면 문제가 정의되면서 동시에 해결된다는 것을 의미한다. 폭포수의 하향식 접근방식으로는 고약한 문제를 해결할수가 없다.

내 공격목표 폭포수 모델이 아니다. 내가 공격하려고 한 것은 매우 많은 사람이 폭포수 모델의 적용성과 효율성에서 보이는 교조적(dogmatic)인 접근 방식이다.

우리 분야의 헤겔이 폭포수 모델만이 소프트웨어를 개발하는 효과적인 방법이며 유일한 진리라고 자신을 방어하기 때문에 결국 아무런 결과도

얻지 못하는 교조주의를 공격하는것이다. 

폭포수 모델의 변종

폭포수 모델은 변종이 많아서 설명하기 쉽지 않다. 전통적으로는 9 단계이지만,  13단계까지 될수도 있으며,

...