폭포수 모델과 한계점

폭포수 모델의 기원

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를 작성하고 있다고하면 하향식구조 개발방법 즉 워터폴모델을 따르는것이다. 

WBS가 다양한 액티비티 중심으로  애자일보드로 표현되기도 하지만, WBS는 필요없는가? 

워터폴과 상관없이 고객 요구사항 폭팔을 막는용도로는 활용해야한다~ 정확하게는 고객의 요구사항이 단계별로 잘 진행되고 있나?

중간점검을 하기위해 별도로 운영되기도 한다. ( 실제 세세한 작업을 모두 표현하고 일치하는것이 이상적이지만, 너무 세세하게 표현한나머지 동일한 Task를  이삼중~ 중복(Jira,WBS,주간작업현황,월간Task취합)으로 관리해야하는 단점이 생길수도 있다. 이거 관리하는 노력으로 설계또는 우리가 올바른 방향으로 가고있는가? Task의 가치를 이해하고 수행하는 시간으로 전환하는것은 중요하다. )

4-코딩

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

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

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

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

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

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

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

 

5-시스템 검증단계

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

 

6-설치인도/유지보수

• 단계 : 인수테스트 종료후, 계획에의해 시스템이 실전 배치가 된다.
• 주의점 : 설계문서와 구현의 불일치에의해 유지보수시 대부분의 정보를 문서가 아닌 코드로부터 얻는다.  초반 버그를 수정하는동안, 장애시간이 급격하게 늘어나며, 오랜동안 운영된후 안정화가되지만 새로운 기능을 추가하기 어려워진다. 이때 폐기를 하고 새롭게 만들것인가의 선택의 절차를 가지게되지만 대부분 오랜된 시스템으로 계속 남아 있을 가능성이 높다.

소프트웨어가 설치되어 하드웨에 포함되어 납품되는 케이스를 이야기하는 부분이며

오늘날은 하드웨어보다는 소프트웨어가 중심이며

대부분의 IT기업들이 클라우드로 전환을 하면서 다음 용어를 알아둘 필요가 있다

 

온프레미스 vs iass  vs sass vs pass : 인프라전문가만 이해하면 되는 용어로 생각하는 케이스가 있으나, IT종사자라면 필수로 구분해야하는 내용이다.

우리의 서비스가 어떠한 형태로 작동이되고 제공이 되는가? 개발뿐만 아니라, 기획 영업 모두 이해해야하는 단어이다.

대부분의 서비스가 어느 한가지형태가 아닌 다양한 형태로 복합구성되어 있기때문이며 선택한 구성요소에 따라

우리 서비스의 핵심문제를 해결해야하는 전략 포인트(개발인력/운영/기획/영업)가 다를수 있기때문이다.

이 형태에따라 SI전략도 완전하게 다를수 있으며 

 

요약

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

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

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

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

하나의 방법이다. 

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

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

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

 

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

폭포수 모델의 문제점

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

 

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

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

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

 

폭포수 모델의 변종

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

대개 6~9단계를 사용하지만 3단계만 사용하는 사람도 있다. 그리고 폭포수모델을 베이스로 사용하다가, 전혀 다른 모델이 생긴 경우도 있다.

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

 

시작과 끝점이 다른경우

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

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

.....

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

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

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

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

소용돌이 모델

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

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

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

점진적 모델

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

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

나선형 모델

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

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

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

폭포수 모델의 대안

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

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

 

• 사시미 : 개발속도와 유연성을 중요시한 일본에서 폭포수를 경험하면서 만든 모델(하향식절차를 간소화하고 약간씩 겹치게만듬, 개인적으로 애자일 인식의 시초라고 보여집니다. )
• 스크럼 : 사시미에서 한번 더 나아가, 하나로 뭉침  (럭비시 밀집하는 모양에서 유례, 럭비공 모양이 됨 )

 

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

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

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

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

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

스크럼은 애들 장난도 아니고, '경험을 공유하기' 위한 깜찍한 임시방편도 아니다.

스크럼은 사람들이 무언가를 달성하도록 헌신하게 하는 진지한 프로세스다.

사실은 너무 헌신한 나머지, 프로젝트가 끝났을 때 팀원들은 정서적 고통에 시달릴 때도 있다.

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

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

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

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

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

 

애자일 인식의 뿌리

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

애자일 인식의 뿌리가되는 시대를 뛰어넘는 고전입니다.