Page History
...
폭포수모델은 형식을갖춘방법이다.
소프트웨어를 개발하는질서 정연하고 체계적인방법이다.
폭포수는 나일강을 따라내려가는 여왕의유람처럼복잡하고장엄한 프로세스이며
수직적인 절차의 제일 하부목표는 성공이며, 규칙이 없는 팀이 처음 적용하기에 도움이될수 있다.
그래서 대개 큰조직에서 소프트웨어를 생산하는데 사용한다.
(또는 비즈니스 모델을 잘 이해하는 쪽이 제일 상부에 있다면, 폭포수모델을 따르는것이 비즈니스성공가능성이 높다.)
한마디로 폭포수모델은 프로젝트의 복잡성과 규모를관리하는하나의방법이다.
- 고약한문제 합당한 해결 책중에....
폭포수 모델의
...
폭포수모델을 이해할때, 대기업 SI프로젝트를 진행하면 따르는 개발모델이기도하고 SI의 부정적인점과 함께, 폭포수모델을 언급하는경우가 많지만
폭포수 모델은 ,과거(최근까지도)에 성공했던 IT기업들이 성공했던 가장많이 사용한 방식입니다.
SI와 폭포수모델을 분리해서 이해할필요가 있습니다.
SI란
윈도우가 나오기 이전 일반인들에게 IT는, 어떤 기능을 가진 컴퓨터(하드웨어)를 사는 것이었습니다. 그런데 PC는 조립이 간단했지만 기업용 서버는 설치 환경까지 고려해야 하기 때문에 복잡했습니다.
그래서 시스템 통합(System Integration)이란 분야가 등장했습니다. 즉 SI는 초기에 사용자가 요구하는 기능을 가진 하드웨어를 만들어 판매하는 행위였습니다.
업체들은 사용자가 원하는 기능을 만들기 위해 솔루션이나 패키지를 설치하고 필요한 기능을 직접 개발하기도 했습니다. 그런데 하드웨어가 발전화되면서 표준화되고 소프트웨어의 비중이 커지게 되자
SI는 자연스레 소프트웨어 개발 아웃소싱을 지칭하는 말이 되어버렸습니다. 초창기 SI시장은 대부분 수작업을 전산화하는 경우로 ‘불확실성’이 적었습니다. ‘주민등록 관련 업무’나 ‘회계 업무’ 등을 생각하시면 됩니다.
오랫동안 반복적으로 해왔던 업무이므로 기성품을 선택하거나 기능을 새로 만들기도 어렵지 않았습니다. 그리고 납품되고 나면 소프트웨어 변경이 거의 필요없었습니다.
이후 IT가 발달하자 온라인 비즈니스가 중심에 서기 시작했습니다.
기존에 없었던 새로운 일들을 바로 시스템으로 만들게 됩니다. 어떤 비즈니스는 매일 변화가 필요합니다. 인터넷 쇼핑몰, 인터넷 뉴스 서비스, 인터넷 뱅킹 서비스 등을 생각하시면 됩니다.
그래서 이 시스템들은 매번 개발자들의 손이 필요합니다. 사업 환경이 수시로 변하다보니 ‘설계 후 개발’을 하는 것도 어려워 졌습니다. 또한 개발이 완료되어도 종료라고 보기 힘들어졌습니다. ‘불확실성’이 높아진 것입니다.
그래서 우리는 SI에서 폭포수모델의 한계점을 이해할수 있습니다.
...
폭포수 모델의 논리적 근거
소프트웨어 개발에는 반드시 필요한 하위 목표가 있다. 하나의 단계를 성공시키면 배열된 다음 목표를 성공시켜나간다. 이렇게 배열된 맨 마지막 순서가 바로 성공이다.
또한 수행하는 업무를 전문적으로 만들며, 전문적인 롤이 폭포수모델의 단계와 일치한다. 경험정도도 반영되는데 일반적으로 초기에 경험많은 고참경험 많은 시니어(착수,요구사항분석)이가
참여하고 다음이 중간레벨(분석,설계) 그다음 직원이 코딩,유지보수등의 업무를 수행한다.
상위 절차가 중요며 일반적으로, 워터폴에서 IT직군은 다음 역활을 수행한다.
- PM : 변화는 곧 리스크이기때문에, PM의 역활이 중요합니다. WBS를 통해 리스크관리를 합니다.
- 기획 : 비지니스 요구사항을 잘정리하여 변경없는 문서를 만들어야합니다. 요구명세가 완성된후에 개발 착수가 가능합니다.
- 설계 : 경험많은 숙련자가 요구명세를 바탕으로 설계를 진행합니다.
- 구현/QA : 구현자는 주로, 코드로 코더로 분류됩니다.
규모에따라 PM+기획 / 설계+구현 동일 사람일수 있지만 절차적인 흐름에는 큰 변화가 없으며 직군이 분리됨에 따라 더 전문화되어 세분화될수 있습니다.있으며
규모에따라 폭포수의 단계가 축소될수 변경 있지만, 설계가 없는것은 포함되지 않은것을 개발 프로세스가 없다라고 보면되겠습니다이야기하기도 합니다.
폭포수모델역시 초기모델의 단점을 극복하고자 변형되어 소용돌이 모델/점진적 모델/나선형등 /나선형/린(프로토타입)등 다양한 개발모델들이 등장하지만등장하게 됩니다.
어떠한 것은 개발조직을 운영하고 다루는 방법에 가까울수 있고 어떠한 것은 개발방법론 그 차체일수도 있습니다.
하지만 이 둘은 크게 다르지 않습니다. 애자일이란 큰 변화가 발생하지만, 폭포수모델의 단점을 극복하려는 수많은 개발모델들은 애자일의 기원으로 볼수 있습니다.
애자일 선언
2001년, 소프트웨어 업계를 주도하는 17인의 리더들이 모여 다음을 선언하였다.
...