폭포수모델 심화

폭포수 모델의 기원

1971년 밀스가 도입한 하향식, 구조적 프로그래밍 모델과 대체로 일치한다.

1985 Boehm - 폭포수모델이 검증된 하드웨어 개발방식에서 도입된것으로 알고있다.

폭포수 모델의 논리적 근거

소프트웨어 개발에는 반드시 필요한 하위 목표가 있다. 하나의 단계를 성공시키면

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

PM관점에서 폭포수 모델

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

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

폭포수 모델

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

각 단계는 다음 단계에 입력을 주지만, 피드백은 없다.

폭포수 모델 세부논의

착수

• 단계 : 상위 경영진 수준에서 수립하는 전략 계획이나 사업을 진행하면서 나온 결과를 토대로 시작할때가 흔하다.
• 주의점 : 이 단계에서 컴퓨팅 전문가의 도움이 필요없다고 결론 짓는다. 대부분 나중에 이것 때문에 문제가 발생한다.

요구사항 수집및 분석

• 단계 : 엔지니어링 생명주기의 시작부분으로 시스템명서,설계문서,인터페이스 요구 명세,개발 계획등으로 구성된다.
• 주의점 : 사용자를 위해 무엇을 해야하는지 설명이 되지만, 시스템이 어떻게 작동될지에대해 관심이 없다. 어떻게는 다음단계인 기초설계에서 이야기가 될수 있다. 여기서 문제가 발생하는데 '무엇'과 ''어떻게' 를 분리해서 별도의 단계로 나누는것이 자연스럽지 않기때문이다. 

기초설계/상세설계

• 단계 : 기능 명세는 요구사항 분석의 '무엇'과 기초설계 단계의 '어떻게'를 연결하는 다리 구실을 한다.
• 주의점: 비즈니스 시스템의 개발자는 상세 설계 때 무척 바쁘다. 너무 바빠서 여러 작업들이 소홀히 되거나 아예 무시되곤 한다. 기술 문서작성자가 이 시점까지 참석하지 않았다면 많은 문서가 비슷한 운명을 겪는다. 사용자 메뉴얼은 완전하지 않고 프로그래머 메뉴얼은 아예 작성되지 않는다.

코딩

• 단계 : 코딩단계는 앞단계와 결합할때도 있지만,다음 단계와 결합할때도 있다.
• 주의점 : 불행히도 코드 작성은 사소하게 보일 때가 흔하다.  하지만 이 단계에서 시스템의 구성요소를 전부 만든다.

이하단계 설명 생략.......

요약

폭포수 모델에 대해서 반드시 알아두어야 할 게 있다. 폭포수모델은 형식을 갖춘 방법이다.

소프트웨어를 개발하는 질서정연하고 체계적인 방법이다. 

나일강을 따라 내려가는 여왕의 유람선처럼 복잡하고 장엄한 프로세스이다.

대개 큰 조직에서 소프트웨어를 생산하는 데 사용하며, 프로젝트의 복잡성과 규모를 관리하는

하나의 방법이다. 

코딩부터 시작하는 회사들이 일반적인 시절과 비교하면 분명 폭포수 모델 도입은 도움이 되었습니다.

하지만  폭포수모델은 다양한 변종을 만들어 냈고, 개발방법론이 될수 없으며

단지 프로젝트 관리 기법이라고 주장하는 사람들이도 생기기 시작하였다. 그 근거로

소프트웨어를 만드는 실제 기법이 결여 되었다란 것이다. 

폭포수 모델의 문제점

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

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

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

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

폭포수 모델의 변종

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

대개 6~9단계를 사용하지만 3단계만 사용하는 사람도 있다.

그리고 폭포수모델을 베이스로 사용하다가, 전혀 다른 모델이 생긴 경우도 있다.

시작과 끝점이 다른경우

비즈니스 시스템일경우 시작점은 상위 경영진이 될수 있다. "조직내 절차,실현가능성" 이 시작점이 될수 있으며

엔지니어링 어플리케이션일 경우 시작점은 "소프트웨어 요구사항 분석" 이 될수 있다.

.....

생명주기의 첫번째 단계 특히 요구사항과 설계 단계에 많은 주의를 기울여왔다. 그 이유는 이렇게 상위 활동에

투자하면 하위 활동을 덜 해도 되고 더욱 신뢰할 수 있는 소프트웨어를 얻을 수 있다는 생각 때문이다.

그러나 이런 생각에는 문제가 있다.

소용돌이 모델

이 모델은 단계들이 한 '덩어리'를 이뤄 구성된다. 이 모델 내 폭포수의 모든 단계가 소용돌이치는 모습 같이

보일때까지 계속 진행되는데, 그 과정에서 이 '덩어리'의 구성은 여러 번 바뀌게 된다.각각의 단계가 갖는

시간적 관계가 같지 않다. (나사에서 사용)

점진적 모델

보잉사-폭포수모델을 분할해서 실행하는것, 기초 설계 단계의 완료까지 보통 폭포수 모델처럼 진행한다.

그런 다음에는 몇 가지 미니 프로젝트를 수행하며 수행 목적은 몇 가지 요구사항을 구현 하는데 있다.(보잉사에서 사용)

나선형 모델

시작 중심점은 프로젝트를 시작하기 위해 필요한 자원을 나타낸다. 프로젝트를 진행하면서 나선이 형성되면,

시스템의 성장은 나선의 지름 변경으로 표현된다. 사용된 자원은 인접한 나선 사이의 거리로 측정한다.

나선형역시 작업을 빨리 끝내려고 무의식적으로 개발한 방법이다.

폭포수 모델의 대안

30년전 기준으로 설명된 모델입니다.

• 프로토타이핑 : 시스템이 어떻게 작동하는지 설명하는 '모델'을 만드는 프로세스
• 즉각모델 : 외부 관찰자에게 모든활동이 동시에 끝나는 것처럼 보인다. 문제해결 분석이 되지 않는 고약한 문제를 해결 할때 사용한다.
• 사시미 : 폭포수 단계를 네개로 줄여, 유연성을 위해 전통적인 단계들을 약간씩 겹치게함 (회 여러 조각이 앞뒤로 약간씩 겹치는데서 유례)
• 스크럼 : 4단계를 한단계로 줄여 겹치게함, 럭비에서 공을 차지하려고 상대팀을 앞으로 밀어야하는데 이때 사용되는 팀의 기본 대형(스크럼)에 유례
• 투맨접근-수갑채우기 : 스크럼 2인용 버전 , 최종사용자와 프로그래머를 함께 일하게하는 방식
• 원맨접근-해킹 : 스크럼 1인용 버전 , 해결할 문제에대한 상세한 지식을 프로그래밍 지식이나 기술과 결합