Page History

폭포수 모델의 기원

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

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

폭포수 모델의 논리적 근거

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

...

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

PM관점에서 폭포수 모델

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

...

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

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

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

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

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

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

스크럼을 최근 도입한 팀이, 엑셀WBS보고서를 탈출하고자 , 지라의 자동보고서를 어떻게 잘구축하였다.

유져스토리를 먹기좋게 가로로 자르냐? 세로로 자르냐? 고민을 했고 결국 자동 보고서와 호환이 되지 않아

먹기좋은 형태가 아닌, 보고서에 잘나오는 형태로 자르게 되었다. ( 기본기능으로 지라는 이부분에대해 아무것도 하지못한다. - 유료 JPQL쿼리로 어떻게 될수는 있다. )

이것에대한 문제는 폭포수모델과 상관없어보인다. 
참고링크 : 

https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/

https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/

폭포수 모델

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

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

폭포수 모델 세부논의

1-착수

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

2-요구사항 수집및 분석

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

3-기초설계/상세설계

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

기초 프로그램 계획단계가 포함될수 있으며

WBS(Work breakdown structure) 작성이 진행될수도 있다.  WBS는 워터폴모델의 계획을 가시화및 추적할수 있으며,

WBS를 작성하고 있다고하면 하향식구조 개발방법 즉 워터폴모델을 따르는것이다. 

4-코딩

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

좀더 먼 미래에 이야기된 DDD에서 이야기된 내용이며~

코딩단계가 결코 사소한 단계가 아닌, 소프트웨어 개발의 핵심이란점입니다.

분석모델이 별도로 존재하는 이분법을 채택하지 않고 설계와 코드를 일치시키는것이 핵심!

코드의 변경이 곧 모델의 변경이라는 점을 인식해야하는 점과, 설계자가 구현을 하지 못해 개발자와 업무의 단절이 생기면

설계자의 지식과 솜씨는 결코 전달되지 않기때문에 실천적 모델(HANDS-ON MODELER)을 각 프로그래머가 수행해야하며

이것은 역활과는 상관없이 코드를 변경하는 책임이 있는 이들은 코드를 통해 모델을 표현하는 방법을 배워야한다란것을 강조하고 있습니다.

5-시스템 검증단계

• 단계 : 모듈테스트단계가 포함될수 있으며, "우리가 시스템을 제대로 만들었는가?" 질문에 답을준다. 착수단계에 이미 만든 테스트케이스를 수행하기도한다.
• 주의점 : 실천배치가되어 발생하는문제를 대부분 잡지 못할수도 있다. 다음 유지보수단계에서 요구사항과 기능명세가 불일치함을 찾을수도 있고 유지보수 초반단계에 폭포수의 모든단계를 다시할수도 있다. 유지보수는 기능개선임에도 불구하고 사실은 기존에 잘못개발된것을 고치는데 더 많은 시간을 쏟아부울수도 있다.

6-설치인도/유지보수

• 단계 : 인수테스트 종료후, 계획에의해 시스템이 실전 배치가 된다.
• 주의점 : 유지보수시 대부분의 정보를 문서가 아닌 코드로부터 얻는다. 버그를 수정하는동안 무고장 시간이 급격하게 늘어나며 유지를 하는 비용이 점점 누적되면서 폐기를 할것인가 절차를 가진다.

요약

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

...

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

폭포수 모델의 문제점

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

...

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

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

폭포수 모델의 변종

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

...

폭포수의 변종은, 폭포수일수도 있지만 폭포수의 단점을 극복하기위해 무의식적으로 생성된 경우도 있다.

시작과 끝점이 다른경우

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

...

( 대부분 구현단계에서 보이지 않는 개발자의 노력을 쏟아붓는다. )

소용돌이 모델

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

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

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

점진적 모델

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

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

나선형 모델

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

...

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

폭포수 모델의 대안

30년전 기준으로 설명된 모델입니다. 오늘날의 기준과 약간 다를수 있습니다. ( 30년전 책이여서~)

...

중요결정과 책임이 점점 수평화되어 갑니다.

하향식접근 방식이 아닌, 중첩이 되며 더 많은 피드백및 수정을 할수있게됩니다.

피드백을 주고받으며 완성해나가기때문에, 훨씬많고 적은 단위의 일이 계속 발생할수 있습니다. 

폭포수에서 스크럼에 근접할수록

• 인접구간의 협력및 커뮤니티 강화
• 다자학습 약한 통제
• 피드백을 통한 인접단계 수정가능
• 배움의 조직적 전파

...

브룩스와 피터스는 우리들, 즉 프로그래머가 소프트웨어 공학에서 긍정적 변환의 핵심이라고 지적한다.

헨리 레거드는 이런 변화를 이루기위해 프로의식이 있어야한다고 한다. ( 이 책에서 설명하는 내용으로, 좋은 개발모델을 도입하기 위해서 사람들의 수준이 보통이상이여야한다고 한다. - 30년전)

최근 개발방법론인 DDD로 거슬러 올라와, DDD의 성공요건을 다음과 같이 설명한다.

DDD처럼 소프트웨어를 개발하는 고급 철학이자 기술관점에서 볼때, 평균 이상의 개발자. 더 정확히 말하면, 매우 좋은 개발자가 필요하다.

정확한 기술, 자발성을 지닌 정확한 사람을 고용하는 것의 중요성을 과소 평가하지 마라.

애자일 인식의 뿌리

30년전 고서 "Wicked Problems,Righteous Solution" 에서 이야기하는것들을 압축하였으며

...